Add JSON web token ID claim

[ashokdelphia]

• Add a JWT ID to the payload. (6243308)

  This is a fairly common optional claim.

  I have a case where I want to track audit records back to the associated authentication event, so being able to identify the token reasonably uniquely would be very helpful.

• Track the original token ID when refreshing tokens. (8b42c57)

  This allows us to tie any authorized request back to the original authentication event, identified by the original token's ID.

  It should also be useful for allowing a stronger blacklist check not just for the token but for any token stemming from the same original token.

• Add check that a new token sets both the token id and original token id to the same value. (2e67fd2)

• Add config option to enforce that tokens should have a token id for verification (and original id for refresh). (a3721e5)

  I think it's preferable to reject these, but for someone upgrading a running service it would be unsafe to start insisting that all tokens have token ids immediately. Having a setting allows the operator to start enforcing it after all of their valid tokens were made by a new enough version of the library, which depends on how they have configured expiration times.

  (I need to update the docs once I know which version the jti change will ship in.)

---

I considered doing this with a custom payload handler, but it's not really possible to get the link back to the original token ID that way, so I can add an identifier, but I can't see a good way to preserve the relationship to the original token.

I'm hoping it's reasonable to always add this, rather than making it configurable, but please let me know if you'd like it to be optional. We could also allow someone to configure their own function for creating an identifier, but I chose to make it a random UUID4 for starters, which I believe satisfies the spec's requirement for a "negligible probability" of colliding identifiers.

I'd like to build on this later by strengthening the 'blacklist' check to disallow the whole (potentially branching) chain of tokens, rather than just the current token at the time the user invalidates their token. But I think this is still useful to ship independently.

I have two use cases this will help me solve:

• associate any authenticated request with the original login event, to enable more thorough investigation of activity associated with a suspicious login
• allow identifying a blacklisted token outside of the django service without needing to share the entire token

(I'll add release notes if the basic approach here seems acceptable.)

[ashokdelphia]

As to the functionality, I'd be happy to merge it if you're done making changes to this PR.

I'm done making changes. I've guessed at the right version this will ship in. Please let me know if you'd like me to adjust anything else before this merges.

[fitodic]

@ashokdelphia and @nigoroll, thank you both for your contributions. It has been released in 1.17.0.

[ashokdelphia]

@fitodic: Much appreciated. Thanks for merging & releasing this and #72.