✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

_{Generated for commit: 20c5dcd. Link to the linter CI: here}

Log of my though process (that hopefully helps me move forwards):

The de-coupeling of _get_metadata_request for consumers and get_metadata_routing that was previously used in both consumers and routers and is now only used in routers is a separate issue than removing the add_self_request in routers by using their _get_metadata_request method, that is still present in them.
I understand I should do it in the same PR nevertheless.

I wonder if we want to fully automate the setting of self requests, or if it should be integrated in MetadataRouter.add(). But if the latter, I wonder if it really makes things simpler, because we would force estimator developers to define a method_mapping in .add, that is not easily available for self requests (or only in a hacky way).
So I tend to fully automate, which means that I'd have to manipulate MetadataRouter.__init__(). I have hardly seen us add any functionality to any init method in scikit-learn, and I think for a good reason (predictability or so?). Still, I will make a suggestion to automate the setting of self requests for router, because otherwise, we force us and developers of custom meta-estimators to pass a complicated method mapping into MetadataRouter.add()...

Since then I need to pass an object into MetadataRouter.__init__(), so I can create a self request, I wonder if I should make the existing owner become an object type, instead of a string, or if I should add a new init param that would be the object. Maybe better to pass a new param, because then the owner string can still get a user-defined name?

But potentially, those could both be merged into the same param, since passing MetadataRouter(owner=self.__class__.__name__, owning_obj=self) seems a bit unnecessary.

I understood that this PR cannot do much about the double-handling of MetadataRouter and MetadataRequest objects (which I had thought it was intending in the beginning), because that depends on several other places and choices taken. But it does part of the job by taking care of certain methods. I will update the PR title to better fit that.

I've experimented with my above idea to add a self-request automatically to routers, but it fails for routers that are pure routers but not also consumers. Given that, I no longer see a benefit in removing or refining the add_self_request method from MetadataRouter. We would still require some input from estimator developers on whether a self request should be added or not.

If that input is done by calling MetadataRouter().add_self_request(self) in get_metadata_routing() or through - in the simplest case, boolean paramater (like add_self_request=True) feels like an implementation detail.

Also, the original change of this PR, the de-tangling of _get_metadata_request and get_metadata_routing methods for consumers doesn't provide a new possibility here, because MetadataRouter().add_self_request had already internally used obj._get_metadata_request().

At this point, I am tempted to think this refactoring is complete, unless there is some specific thing that we want to do with add_self_request?

This PR makes the code more readable, because we can clearly see if we deal with a consumer based on the method called on an object. It also adds some improvements to the internal and the API docs and personally, it has given me more insights and more ideas for refactorings (which I will open separate PRs for).

What is left that I will go through our docs and examples to check whether the right method is used everywhere. I will do that and then un-draft this PR. Do you consider it complete, @adrinjalali?