Document extracting authentication from custom metadata

[Adrastopoulos]

Context

GrpcSecurity.authenticationExtractor() is public and takes any GrpcAuthenticationExtractor, but every extractor that ships reads a fixed location: BearerTokenAuthenticationExtractor and HttpBasicAuthenticationExtractor both read Authorization, and SslContextPreAuthenticationExtractor reads the SSL session.

So credentials that arrive in some other metadata entry (an opaque session token, an API key, a principal set by an upstream proxy) have no documented path, even though the extension point already handles them fine.

Two behaviours of that extension point are also untested:

• registered extractors are sorted with AnnotationAwareOrderComparator, so @Order controls precedence
• the composite returns the first non-null Authentication, so a custom extractor composes with the built-in ones rather than replacing them

Direction

• document authenticationExtractor() with a worked example reading a non-Authorization metadata key
• tests covering the ordering and first-non-null behaviour, driven through the interceptor GrpcSecurity builds