Login with "next" view that requires OTP and user that requires setup loses the "next" parameter

[cjsoftuk]

Expected Behavior

When you have a target view from the login process passed in via "next" that's protected with the OTPRequiredMixin and the user is not set up with OTP, two_factor should redirects the user to the OTP setup view, preserving the "next" URL.

Current Behavior

The OTP Login Views send the "next" url to the session (https://github.com/jazzband/django-two-factor-auth/blob/master/two_factor/views/core.py#L188), but it is then never reloaded from the session in https://github.com/jazzband/django-two-factor-auth/blob/master/two_factor/views/core.py#L461

Possible Solution

Change https://github.com/jazzband/django-two-factor-auth/blob/master/two_factor/views/core.py#L188 to hand the "next" URL off to the setup view, rather than saving it in the session. For example at https://github.com/jazzband/django-two-factor-auth/blob/master/two_factor/views/core.py#L189

            return redirect(
                '{view_url}?{query_string}'.format(
                    view_url=reverse('two_factor:setup'),
                    query_string=urllib.parse.urlencode({'next': self.get_success_url()})
                ))

This is possibly not going to cope with all edge cases, however, does cope with the specific use case I have.

Alternatively, it would be possible to change the Setup view to read from the session, however, I feel that the Login view should tell Setup where to go after setup, not Setup "finding out" via some stateful method using the session.

Steps to Reproduce (for bugs)

1. Set up a view using OTPRequiredMixin (e.g. oauth2_provider's AuthorizationView for authorizing an app with a Bearer token)
2. Attempt to log in to this workflow (e.g. as an OAuth2 login flow from oauth2_provider) with a non-2FA enabled account
3. Watch as you get bounced to the setup
4. Complete setup, and watch as you are not returned to the original oauth2 authorize page, but instead to "two_factor:profile" (by default).

Context

Your Environment

• Browser and version: Chrome Version 109.0.5414.74 (Official Build) (64-bit)
• Python version: 3.9
• Django version: 3.2.16
• django-otp version: 1.1.6
• django-two-factor-auth version: 1.15.1
• Link to your project: Not available - Commercial application