Adds new refresh tokens to OutstandingToken db.

[thecarpetjasp]

Fixes the issue #363 where new refresh tokens issued out do not get added to the OutstandingToken db.

The issue was resolved by adding a method to the Token class called outstand, which checks if the token is in the outstanding table, and adds it if not.

When ROTATE_REFRESH_TOKENS is set to True, the TokenRefreshSerializer calls the .outstand() method on the new refresh token that is issued.

All tests ran fine, except for test test_it_should_blacklist_refresh_token_if_tokens_should_be_rotated_and_blacklisted. The reason for this was it was asserting that outstanding table has 1 token.

However, since this bug is now fixed, there should be in fact 2 tokens in the outstanding table. One for the initial refresh token issued during authentication, and the second token which is issued during a refresh, which was implemented in this PR with .outstand(). So I have changed that test to assert two tokens in the table, which is now correct.

[robertalexa]

Hey guys,

Unless I am mis-understanding some things, I belive this PR has introduced a bug.

If you follow the installation instructions in the Documentation you will see that nothing gets added to INSTALLED_APPS unless you require localization (which seems like an optional step).

That being said, the blacklist app is not getting used.

If that app is not used, the new outstand function will now throw an error because the model it relies on depends on rest_framework_simplejwt.token_blacklist (in INSTALLED_APPS) in order to have the migrations (see Blacklist app Docs).

So as far as I can see, this PR introduced a dependency on OutstandingToken that does not exist by default.

Whether the Blacklist app should be always used or not, is something else to consider.

Can one of you have a look please?

LE: I am prepared to accept that maybe the way I have installed this is wrong, and if so, please shed some light.

[Andrew-Chen-Wang]

Thank you for catching that! No, this is a bug @robertalexa