BinderTransport's TRANSPORT_ATTR_LOCAL_ADDR is different than its peer's TRANSPORT_ATTR_REMOTE_ADDR

[jdcormie]

Today:

• BinderClientTransport's remote is the AndroidComponentAddress passed to bindService(), which makes sense.
• BinderServerTransport's local is its server's "listening" address, a meaningless concept constructed by calling AndroidComponentAddress.forContext() on the Service. This is basically an Intent with a ComponentName but no other fields set. Meaningless, because without considering the onBind() implementation and the setup there's no reason to believe any client could actually bind to such an Intent.

In the other direction

• BinderServerTransport's remote is a BoundClientAddress wrapper around the client's uid, which makes sense.
• BinderClientTransport's local is another case of AndroidComponentAddress.forContext() called on the client's source Context. This address is meaningless because it can't

This asymmetry is one of the reasons why AbstractTransportTest.socketStats() currently fails.

We could fix this by letting BinderClientTransport's local be a BoundClientAddress wrapper around its own UID.

I don't know what to do about BinderServerTransport's local. The client's actual bind Intent is mostly available from onBind() but we encourage Services to ignore it and always return the same BinderServer.getHostBinder().

[jdcormie]

TGP found that changing BinderClientTransport's TRANSPORT_ATTR_LOCAL_ADDR to a BoundClientAddress matching the server caused no breakage (http://fusion2/presubmit/805544078). I'll proceed with this unless there are objections ... ?