feat: Removes pyo3 and derives tokens directly in Rust

[tarikeshaq]

Description

We were using pyo3 in two places to call into Python code:

1. When verifying an FxA oauth access token, calling into PyFxA's verify_token function - to verify an oauth token, which would first try to validate the token directly using a JWK stored in our environment variables, or otherwise it would trigger a /v1/verify/ call on FxA's oauth server, asking FxA to verify for us
2. When generating a new Token to be used against storage server, we called into tokenlib's make_token and get_derived_secret

This PR replaces both usages of pyo3 with Rust code implemented directly in the tokenserver.

Testing

I've tested a local firefox connected to FxA's stage, and my local environment with tokenserver and syncstorage and verified that:

• Tokenserver can verify tokens properly if given the JWK's in its env variables
• Tokenserver can send the network request properly to FxA when it cannot verify the token locally (think FxA rotated their JWKs)
• Tokenserver can issue tokens, and those tokens can be used correctly for sync against syncstorage

My local firefox syncs successfully with the changes in this PR, however, Out of abundance of caution we should run end-to-end tests and deploy this first on a canary if we plan to take it

TODOs

• [x] Add unit tests for both verify and get_token_and_derived_secret
  • [x] verify
  • [x] token generation
• [x] Document the hidden policies here so they're not hidden, eg: how the tokenserver tokens are derived, and how it validates the FxA access token, this was documented in the code for now as doc strings on a public API

Issue(s)

Closes SYNC-3528.

[tarikeshaq]

Alrighty this should be in a good stage for a first-round review

@jrconlin @pjenvey I know there is a lot going in the autopush world, so no rush getting to this - it is not urgent and I wouldn't want to interrupt your flow over there but I'll keep my eye on the patch for when ya'll get the time

[ethowitz]

Just stopping by to say this is awesome and I'm glad it's happening 🎉

[tarikeshaq]

This is why I love working in the open - Great to see you @ethowitz!!

[jrconlin]

Part of me would love to put the python replacement stuff behind a feature flag, maybe break the functions out of tokenserver-auth/lib.rs and into either lib-py.rs or lib-rs.rs (same with oauth.rs) and bring them in via a flag? That would let us land this code but keep it out of production use while it gets reviewed.

Fortunately a LOT of this PR is general cleanup.

[tarikeshaq]

Thank you @jrconlin!! I like the suggestion of using rust features for this so it's safer (also easier to rollback and canary, etc etc)

I went ahead and moved the python implementation behind a rust feature, and removing that feature will have the Rust implementation

[tarikeshaq]

(the ci failures are unrelated and should be fixed in #1518 )