Split MetadataSegmentView in two implementations: caching and direct RPC call

[leventov]

Currently, MetadataSegmentView violates the Single Responsibility Principle. There should be two separate implementations of the API, one is caching and another making direct RPC, and the choice between them should be done during Dependency Injection binding.

FYI @surekhasaharan

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been closed due to lack of activity. If you think that is incorrect, or the issue requires additional review, you can revive the issue at any time.

[gianm]

I'm not sure if splitting this 1 thing into 3 things (interface + two concrete impls) makes it better. As one class with an isCacheEnabled flag it is pretty easy to understand. I suppose it might be somewhat nicer if done with a design like:

1. Non-caching impl exists and is super simple
2. Caching impl also exists, and contains a non-caching instance within itself, acting as sort of a caching wrapper
3. Both implement the same interface

Will reopen this issue / leave it open in case the conversation continues.

[leventov]

In the future, we may split it and add a third implementation: brokers polling metadata store directory (proposed here: #6834 (comment) and discussed below in that issue). The proxy design still doesn't make sense to me.