Expose InternalServer as a transport attribute in ServerImpl

[vlcekmilan]

This change exposes the InternalServer as a transport-level attribute on ServerTransportListenerImpl, making it available to ServerTransportFilter implementations and downstream consumers via Attributes.

Changes

1. Added a static Attributes.Key named TRANSPORT_SERVER_ATTR with the key "io.grpc.Grpc.TRANSPORT_ATTR_SERVER_TRANSPORT"
2. In transportReady(), the transportServer reference is set on the Attributes before transport filters are invoked, so it is accessible throughout the request lifecycle

Why
We need access to the underlying ServerTransport from within a ServerInterceptor to force-close the transport connection when an external session expires.

In our use case, we have a ServerInterceptor that authenticates incoming RPCs against an external session management system. When a session isestablished, we register a close handler on it. If the external session is later invalidated or expires, the close handler fires and needs to shut down the underlying transport so the client is forced to reconnect and re-authenticate.

Currently, there is no way for a ServerInterceptor to access the transport layer to force-close a connection. The interceptor can reject individual RPCs via call.close(Status.UNAUTHENTICATED, ...), but it cannot terminate the transport itself.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: vlcekmilan / name: Milan Vlcek (d49ab2f)

[vlcekmilan]

Hello @ejona86, could you pls review this?

[ejona86]

exposes the InternalServer

That's internal. We're definitely not going to expose it directly. We'd have to do something indirectly.

When a session isestablished

How is a session established?

so the client is forced to reconnect and re-authenticate.

Is authentication an RPC, or part of TLS handshake? Or are you doing something with ServerTransportFilter?

[ejona86]

If the external session is later invalidated or expires

FWIW, predictable expiration could potentially be handled by maxConnectionAge(). But if sessions can be suddenly invalidated, that's quite a different thing.