Remove ConnClient, it's pointless now

[bleggett]

No description provided.

[howardjohn]

Is there some context on why we want to do this? To me this seems to break the abstraction -- before, the h2 client was just a pure http2 client without Istio-isms. Now we are leaking istio specific pooling semantics into the general h2 client?

[bleggett]

Is there some context on why we want to do this? To me this seems to break the abstraction -- before, the h2 client was just a pure http2 client without Istio-isms. Now we are leaking istio specific pooling semantics into the general h2 client?

Yep, fair - I thought so too (I added ConnClient in the first place I think), but when passing back thru here ConnClient started to look redundant to me.

• ConnClient does nothing but hold a H2ConnClient and a WorkloadKey.
• H2ConnClient and ConnClient are both only used internally by the pool in the first place.
• H2ConnClient is already an Istio-specific client, in the sense that we wrote our own, only we use it, and only in this spot.
• In the only places we use H2ConnClient, it is a critical invariant that it should be unambiguously tied to a specific WorkloadKey.
• WorkloadKey isn't really pooling-related, it's just a unique key that identifies the src/dest of the workloads the H2ConnClient is bound to, for its lifespan. The pool builds on the assurance that H2ConnClients are not "multi-tenant" in this sense.

So the tl;dr is that yes, it breaks the abstraction in that it makes H2ConnClient import e.g. Identity and such, but the abstraction itself serves no purpose here, so the ConnClient wrapper is functionally redundant.