If I understand this change correctly, memory info is now going to be retrieved from the browser process, instead of the renderer process. Is this expected to degrade the response time of this API, then? (I want to use this API, but will call it many times per second so am sensitive to its performance)

@pushkin- every child process including the browser registers itself as a client with the resource coordinator service that lives inside the browser process, the coordinator is interface that can be used to talk with the clients to get respective memory dumps. At the end of day, the clients are responsible to collect the dumps and send them to the coordinator.

This PR only changes the point of access to the coordinator interface, even before this PR accessing the coordinator from the renderer causes it talk to the browser process via mojo to get the interface. With this PR it makes it clear where the coordinator lives and there is no behavior change.

No Release Notes

I was unable to backport this PR to "12-x-y" cleanly;
you will need to perform this backport manually.

I was unable to backport this PR to "13-x-y" cleanly;
you will need to perform this backport manually.

I was unable to backport this PR to "14-x-y" cleanly;
you will need to perform this backport manually.

I was unable to backport this PR to "15-x-y" cleanly;
you will need to perform this backport manually.

@deepak1556 has manually backported this PR to "13-x-y", please check out #31305

@ppontes has manually backported this PR to "12-x-y", please check out #31342