grpc: add PeerInfo to client's ResponseHeaders and Trailers

[dfawley]

Also: return PeerInfo from Transport::connect instead of SecurityInfo (yes, I know I just changed it to produce SecurityInfo) so that the subchannel can set the full PeerInfo in Trailers when producing errors locally, since the address of the subchannel may be relevant to those errors.

FWIW I wanted to make the subchannel apply an interceptor that could always set PeerInfo in response streams (either ResponseHeaders or in Trailers-only responses), but because the field is mandatory in ResponseHeaders, the transport would need to set it to some default/empty value, which felt wrong. Anything producing a ResponseHeaders or Trailers should ensure the PeerInfo is set correctly.

cc @joshuatants as FYI - this is the change that will provide you with the ability to determine the server's address.

[dfawley]

@arjan-bal - I had to merge in the cancellation changes that you recently submitted. I'm a little uncertain about the tonic behavior if we call cancel on the token after the stream has ended naturally -- i.e. the tonic recv stream returns Ok(None) or Err(status).

In these cases, IIUC tonic itself should send a RST_STREAM(NO_ERROR) as soon as the server ends the stream (via trailers or RST_STREAM) if the client was not already half-closed, or do nothing if it was, and ignore the cancellation token. Do you know if tonic is already doing all this correctly?

[ejona86]

Didn't have time to look at it deeply.

[ejona86]

Do we really want to clone the entire thing? I see we're cloning the entire thing for CallCredentials already. Are we going to Arc things inside Attributes instead, like the client's certificate?

[dfawley]

Attributes is a linked list with Arc'd nodes, so a clone of PeerInfo is fairly small:

• Two Addresses, each with &'static, ByteStr (contains Bytes whose data is Arc'd), Attributes (Arc'd)
• One SecurityInfo with &'static, SecurityLevel (3 value enum with no data), and Attributes (Arc'd)

I do want to delete the Attributes from Address, so it would be down to two Arcs: the ByteStr and SecurityInfo.

The tradeoff would be simplicity for performance. If PeerInfo needed to be mutated in the stack somewhere, it might be worse if it was Arc'd. But, I wouldn't expect that to happen, so maybe it's best in its own Arc?

I think we could change this in a hidden/backward compatible way if we wanted to convert it to hold Arc<InnerPeerInfo>. The accessors just hand out references, which could be references to the value inside the Arc, and PeerInfo is immutable.

[ejona86]

Local address is in the peer's information?

[dfawley]

I did 👀 at this as well. PeerInfo->ConnectionInfo? We call it Peer in Go and have the local address there (just FYI, not as justification; it happened that we added it later there): https://pkg.go.dev/google.golang.org/grpc/peer#Peer