Add option to allow inactive user authentication and token generation

[zxkeyy]

The problem:
Some specific use cases require inactive users to be able to authenticate, but that is prevented by the code even though django allows it with 'AllowAllUsersModelBackend'.

The changes:
Added new authentication class and authentication rule that allow for inactive users
Added tests for them as well

So instead of having to rewrite the code allowing inactive users can be done by adding these settings:

SIMPLE_JWT = {
      "USER_AUTHENTICATION_RULE": "rest_framework_simplejwt.authentication.allow_inactive_users_authentication_rule",
}

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': [
        'rest_framework_simplejwt.authentication.JWTInactiveUserAuthentication',
    ]
}

AUTHENTICATION_BACKENDS = [
    'django.contrib.auth.backends.AllowAllUsersModelBackend',
]

closes #607

[Andrew-Chen-Wang]

Thanks for reaching out! So the offending line of code in the original authentication backend is:

        if not user.is_active:
            raise AuthenticationFailed(_("User is inactive"), code="user_inactive")

I would much prefer if we made a setting called "skip check is_active" where the setting defaults to False (as in by default check is_active) because I can also see how some users may not create an is_active flag. This would knock out two use caes. Ensure the default authentication rule function also checks for this setting.

[zxkeyy]

@Andrew-Chen-Wang
Updated based on what you suggested, i also changed the check for user.is_active with the user authentication rule since it seems limiting for it to be hardcoded, i still need someone smarter to tell me if this breaks backwards compatibility or something.

[Andrew-Chen-Wang]

Almost ready, just a few changes

[Andrew-Chen-Wang]

This class shouldn't be needed given the new settings

[zxkeyy]

oops, i missed it. should be good now

[Andrew-Chen-Wang]

we want to only validate the user is active, not run the authentication rule, since this function is just looking to fetch a given user. Good forward thinking, but yes this would break backwards compatibility

We can revisit this if you open a GitHub issue

[zxkeyy]

After thinking about it harder i see how it could cause a problem if a user made their own rule, addressed in latest commit.

[Andrew-Chen-Wang]

thank you! this looks great