feat(clients): implement JWT bearer auth

[matt-codecov]

client implementations don't care about token content so these PRs are simple plumbing

i would still like to enable authz enforcement in our client e2e tests but this PR currently does not include that

Ref FS-202

[lcian]

LGTM, when we roll out the auth we should document that this is always required in saas, we can do so in a follow-up

[jan-auer]

This requires the user to know too much about our auth mechanism and do too much manually. The follow-up PR shows this very well: https://github.com/getsentry/objectstore/pull/231/files#diff-2901f12558868d8df8503eb8c709ebe697eaf471057eabeadede4c292f869fbeR29-R59

Compare with the implementation we had initially for this, which just required to configure a secret, and the client did all the rest.

We should change it like so:

• The client is configured with options it needs to create tokens itself
  • (mandatory) The private key. If missing, no tokens will be issued.
  • (optional) A set of permissions. Builder defaults this to all permissions.
  • (optional) An expiry duration (not timestamp!). Defaults to something reasonably short, like 60s.
• The session is responsible to create the token
  • References above options from the client or gets them injected
  • Together with the session's usecase and scopes it builds the token
  • Applies it to all outgoing requests on the session.
• Caching:
  • The token can be reused until it is close to expiry, session then regenerates it on-the-fly
  • In practice, this means the session initializes w/o a token and the first request creates it

[matt-codecov]

i still disagree for all the reasons i've argued previously, but i will take your direction

[linear]

FS-202 Implement (optional) JWT in Clients

[matt-codecov]

replacing with:

• rust PR feat(auth): rust client support for bearer auth #237
• python PR feat(auth): python client support for bearer auth #240