Since we are doing lot of wrapping on the LoadBalancer API, and Subchannels are passed through various interfaces, a wrapped Subchannel will require a lot of care to make sure it's consistent on all APIs, e.g.,

1. The Subchannel from createSubchannel() should be the same objects that's passed to SubchannelStateListener on every wrapping level.
2. An upcoming ORCA load reporting API is another example (xds: implement lb policy backend metric api #5639 (comment)).
3. The Subchannel from PickResult will have to be unwrapped as well. ManagedChannelImpl assumes the Subchannel from PickResult is the real "SubchannelImpl".

Possible solutions:

1. Move LoadBalancer.Helper methods that accepts Subchannel to the Subchannel class, e.g., updateSubchannelAddresses(). Stop passing Subchannel to the listeners. But that requires a start(), which is a non-trivial API change on the current Subchannel, but could be considered for new APIs.
2. The opposite of above -- move all state-mutating methods, e.g., shutdown(), requestConnection() to Helper, eliminating the need for wrapping Subchannel.
3. Provide a util to help correctly wrap Subchannel while keeping the consistency.
4. Add another identity object to Subchannel. This could also used by ManagedChannelImpl to retrieve the real "SubchannelImpl" from PickResult.

Solutions 2 and 5 wouldn't go along with our plan of changing Subchannel attributes to an object, because a wrapping Helper can only add its own stuff on that object by wrapping it, which ends up the need for unwrapping it on the Subchannel. Otherwise they seem to work well.

@ejona86 @voidzcy