[service-bus] Track2 - remove receiver and sender caching from track 1

[richardpark-msft]

Track 1 had a singleton architecture that would ensure only a single receiver and sender were created per entity.

This caching seems to have little benefit compared to just giving the user control over managing the lifetime of senders and receivers.

Oddly enough this is related to #7936, which spurred all of this investigation and helped uncover this caching.

Some items to consider:

• These cached receiver/senders are stored as part of the ClientEntityContext and need to removed from there. That should give us all the places we need to chase down.
  • BIG NOTE: as part of the fix for [service-bus] Make close() work when a connection is in process #8746 I noticed some unintended dependencies in how
    Receiver gets initialized - the context.streamingReceiver and context.batchingReceiver
    assignments in _init() are how the Receiver itself can properly handle locking when
    doing open()/close(). This is less of a big deal when we start auto-initializing Receivers after
    they're created by ServiceBusClient.
    (will be fixed with [Service Bus] Remove ClientEntityContext #9710 and [service-bus] init() refactor to propagate abortSignal support. #10578 which unifies the init() logic between all the link entities)
• This might be a good opportunity to actually return a Closeable instance from subscribe(), helping solve [Service Bus]: registerMessageHandler is not deterministic #7986 (for track 2) by giving us a natural place for the user to know that a connection has been established. (fixed by [service-bus] Adding in support for stopping a Subscription for session subscribe #9849)
• (via @ramya-rao-a ): All clients for the same queue/topic/subscription used the same $management link. This was very intentional. Where as in Track 2, each sender, receiver and rule manager gets to have their own $management link. We need to look into what performance hit (if any) we see with this approach. (will be fixed by [Service Bus] Remove ClientEntityContext #9710, decision was to share the management link)

[richardpark-msft]

CC: @ramya-rao-a who had the history on this particular bit of behavior.

[ramya-rao-a]

Speaking of caching, in Track 1, all clients for the same queue/topic/subscription used the same $management link. This was very intentional. Where as in Track 2, each sender, receiver and rule manager gets to have their own $management link. We need to look into what performance hit (if any) we see with this approach.

[richardpark-msft]

Speaking of caching, in Track 1, all clients for the same queue/topic/subscription used the same $management link. This was very intentional. Where as in Track 2, each sender, receiver and rule manager gets to have their own $management link. We need to look into what performance hit (if any) we see with this approach.

Added to the list at the top.

[ramya-rao-a]

Also, now that we dont have intermediate clients for Queue, Subscription and Topics, we don't really need the ClientEntityContext class. We should be able to just use the ConnectionContext class like we did in Event Hubs

[ramya-rao-a]

#9710 is the first step towards this goal

[richardpark-msft]

We had some other little issues - the bulk is taken care of with @ramya-rao-a 's PR and then the rest is basically mopped up with our unification work. Once those PRs are closed I think we can consider this one done (all of them are in the issue description now)

[richardpark-msft]

All PRs have been merged.