auth: support multiple AUTHORIZATION_TOKEN in single message

[michalhosna]

Preparation for #530

Related:

• Semantics of multiple AUTHORIZATION TOKEN parameters in one message moq-wg/moq-transport#1838

---

This change is 

[mondain]

Reviewable

I found two blocking authorization-contract issues.

[IMPORTANT] Invalid tokens must not be dropped when another credential permits the operation. authenticateSetup() and authorize() currently continue after every verification error and accept the message if another token or the session grants authorize it. Section 9.2.2.1 of the checked-in draft-16 says a message containing a well-formed Token structure but otherwise invalid AUTHORIZATION TOKEN parameter MUST be rejected with MALFORMED_AUTH_TOKEN. The existing AuthorizeGarbageRequestTokenDoesNotBlockSessionGrants and AuthenticateSetupAcceptsAnyOfMultipleSetupTokens tests codify the opposite behavior. I added a temporary diagnostic with a bad-signature request token followed by a valid token; the expected rejection failed because authorize() returned success. The linked WG issue #1838 is still open and explicitly identifies this conflict, so the current draft behavior should remain authoritative until that discussion changes it. Please fail on a recognized token's verification error and add negative request/setup coverage; union grants only across tokens that are all valid.

[IMPORTANT] A request token no longer overrides the session grants. allow_request_token_override is documented in docs/config.md, config.example.yaml, and the generated schema as replacing the setup grants for that request. The new requestGrants || sessionGrants check makes the sources additive instead. That means a request token intended to narrow authority cannot do so: a broad session grant still authorizes the operation. A temporary diagnostic with a valid Publish-only request token and a Subscribe session grant expected Forbidden, but returned success. When override is enabled and at least one request token is present, please evaluate the request-token pool instead of the session pool; use session grants only when the request carries no matching token. If additive behavior is intentional, the setting and all three operator-facing descriptions need an explicit contract change.

For verification, exact head 138350f6 built successfully, all 36 focused auth/filter/context tests passed before the diagnostics, and git diff --check is clean.

[michalhosna]

@mondain I am lost at what reaction/action do you expect from me?

Both of those findings work as I intended, do you disagree with my intention or are you raising a question if this was the intention?