✔️ 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 andget_metadata_routing that was previously used in both consumers and routers and is now only used in routers is a separate issue than removing theadd_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 inMetadataRouter.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 manipulateMetadataRouter.__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 intoMetadataRouter.add()...

Since then I need to pass an object intoMetadataRouter.__init__(), so I can create a self request, I wonder if I should make the existingowner 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 theowner string can still get a user-defined name?

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

I understood that this PR cannot do much about the double-handling ofMetadataRouter andMetadataRequest 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 theadd_self_request method fromMetadataRouter. 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 callingMetadataRouter().add_self_request(self) inget_metadata_routing() or through - in the simplest case, boolean paramater (likeadd_self_request=True) feels like an implementation detail.

Also, the original change of this PR, the de-tangling of_get_metadata_request andget_metadata_routing methods for consumers doesn't provide a new possibility here, becauseMetadataRouter().add_self_request had already internally usedobj._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 withadd_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?