[Feature] Allow DynamicAccessController to access the HTTP Request headers in order to implement JWT token authentication

Nobody has claimed this yet.

### Willingness to contribute

Yes. I can contribute a fix for this bug independently.

### Feature Request Proposal

My understanding from code is that the Router, the Controller and the Server expose an HTTP endpoint.
In this case implementing token based authentication (like JWT) is pretty easy, because we can simply require the client to pass the token in a HTTP header.

The only thing we need to do is to allow the DynamicAccessController to access the HTTP request headers (and possibly cache the result of the validation but attaching it to the Netty Channel)

The implementation on the clients should be pretty straighforward, as we only need to let the users configure the token and pass it in every HTTP request as an header

### Motivation

> #### What is the use case for this feature?

Implementing JWT authentication (and some day also OAuth2)

### Details

_No response_

### What component(s) does this bug affect?

- [X] `Controller`: This is the control-plane for Venice. Used to create/update/query stores and their metadata.
- [X] `Router`: This is the stateless query-routing layer for serving read requests.
- [X] `Server`: This is the component that persists all the store data.
- [X] `VenicePushJob`: This is the component that pushes derived data from Hadoop to Venice backend.
- [X] `Thin Client`: This is a stateless client users use to query Venice Router for reading store data.
- [X] `Fast Client`: This is a stateful client users use to query Venice Server for reading store data.
- [X] `Da Vinci Client`: This is an embedded, stateful client that materializes store data locally.
- [X] `Samza`: This is the library users use to make nearline updates to store data.
- [X] `Admin Tool`: This is the stand-alone client used for ad-hoc operations on Venice.

Trace how DynamicAccessController is invoked by the Router, Controller, and Server, then identify where HTTP request headers are available. Define how header access and any validation result should be exposed to the controller, and verify that JWT authentication can be implemented consistently across the affected HTTP endpoints.

Written by the indexing model from the issue text.