These thoughts stem from some completely unreleated work. I originally intended to simplify the interfaces of ClusterInfo and try to aggregate all HTTP reletated options to a single HttpProtocolOptions. Then, I found that the TransportSocketFactoryContext instance of cluster is prapagated in the multiple-levels call and I did a simplifiation (see #26438).

When I was doing #26438, I found that there are lots of types of factory context. All these factory contexts have some similar interfaces that used to access the server-wide resource. In almost all the cases, these interfaces' impl would be a simple wrapper to the interfaces of a server factory context reference.

I am thinking could we make things simpler, could we just add a serverFactoryContext() to these factory contexts to return a reference. This reference will provides server-wide resource accessing.
The type of reference could be ServerFactoryContext or CommonFactoryContext or FactoryContextBase, it depends on the set of interface that we want to expose.

Then we will have a clear delimitation between the server-wide resource and context-wide resource. And these factory contexts needn't inherit and implement the interfaces of CommonFactoryContext or FactoryContextBase.

And by this way, the code should be eaiser to maintian. Take #23903 as an example, in the #23903, we changed the return type of admin() interface. Although this interface is only accually implemented by the server, we still need to change almost every factory context because almost all factory contexts inherit the FactoryContextBase. (From this perspective, composition over inheritance).