bug: rework Tokenserver load tests for local OAuth verification

[ethowitz]

Description

Now that we're caching FxA's public OAuth JWK on the Rust Tokenserver, OAuth token verification is happening local to Tokenserver: when a JWK is passed in, the PyFxA library verifies tokens locally using PyJWT instead of making requests to FxA's OAuth server. The load tests were previously written under the assumption that tokens were always verified remotely, so this PR adapts them to "forge" valid tokens.

The idea is that we can generate a set of RSA keys, use the public key to be the primary JWK used by Tokenserver for verification, and use the private key to generate OAuth tokens with valid signatures in the load tests.

Testing

I tested this by following the steps in the load testing README and ensuring that each of the test cases passed successfully.

[ethowitz]

We don't need this file anymore now that we don't use a mock OAuth service for load testing

[pjenvey]

Looks good.

As I'm revisiting JWK caching I had a question -- when you ported over the "hardcoded JWK" feature from the python version, did we confirm that tokenserver stage/prod are using it?

Reason I ask is I noticed PyFxA also does at least some caching of verification requests (bbangert mentioned similar clients typically do some caching). Might this caching be sufficient vs the "hardcoding"?

[ethowitz]

@pjenvey Yeah, the values are set for both stage and prod. If desktop and mobile clients cache their own tokens, I'm guessing most (or at least many) of the requests Tokenserver receives are for never-before-seen OAuth tokens from FxA, which IMO would make caching the JWK worth it. If you want, I can look into the expiry time for tokens granted by FxA and then query the Tokenserver logs to see how many repeated requests we get from a given UID within the expiry timeframe. That should tell us (very roughly) the number of hits we get in the PyFxA cache (although each container will have its own cache, and there's no guarantee that a given user will be sent to the same container twice)