Implement more lax JWT decoder

[ChrisPenner]

Overview

The jwt lib fails on EdDSA jwts even though it doesn't verify the signature 😞

This means switching to EDDSA HashJwts isn't possible for now; which is fine I can keep those as HS256 JWTs, but I want to fix this now so we can potentially switch it in the distant future if we have to :)

Plus this removes the dependency on jwt, which is probably good since we should be using jose for everything where possible.

Implementation notes

Manually unpack and decode the jwt when reading HashJWTs rather than depending on the jwt lib.
It's really easy to do, and it's part of the spec so it's not going to change.

Test coverage

Tested against Share's push/pull transcripts

[aryairani]

Is it:

• The jwt lib fails on EdDSA jwts
• We were planning to use jwt for this, but we can't
• PR gets rid of jwt altogether
• There's nothing else we can easily use to do EdDSA right now, but maybe we can later with a bigger refactor

?

[ChrisPenner]

@aryairani

The jwt lib fails on EdDSA jwts

Yes.

We were planning to use jwt for this, but we can't

jwt was already in use, but is incompatible with EdDSA jwts, which we may use for HashJWTs (or other JWTs) in the future.

PR gets rid of jwt altogether

Yes. This was the only thing we were using it for, and if it can't do that part right then we don't need it at all. I re-implemented the function we were using in a dozen lines

There's nothing else we can easily use to do EdDSA right now, but maybe we can later with a bigger refactor

This change allows trunk builds of unison to use EdDSA right now, but since old clients would break upon receiving EdDSA jwts we shouldn't switch yet. This PR changes the code to be future proof so we can support any flavour JWT someday in the future once enough folks have upgraded :)

No rush though, the backend can continue to support old JWTs.