Release 2.4.6

Adding django 2.2 support
Adding some new relic custom metrics
Clean up

2.4.5: minor fixes to recent releases

- restore public api toggle constants
- add permission of AllowAny to the csrf endpoint

The toggle constants for oauth scopes are used outside of
edx-drf-extensions (in edx-platform), so these constants must survive
and stay separate. NOTE: This problem was introduced in 2.4.2 while
edx-platform remained on 2.4.0. This will be fixed in edx-platform
while upgrading.

This fixes a csrf endpoint bug introduced into the 2.4.3 release,
where an IDA that had a default permission of DjangoModelPermissions
would start failing on this endpoint.

ARCH-1269

2.4.4: Remove jwt_refresh_cookie

The login_refresh endpoint in the LMS was updated to be based on the
user's session, rather than requiring an additional refresh cookie, so
removing any references to the unused refresh cookie and
JWT_AUTH_REFRESH_COOKIE setting.

ARCH-418

2.4.3: remove jwt authentication from csrf endpoint

The main purpose of this commit is to remove the IsAuthenticated
permission from the /csrf/api/v1/token endpoint. The permission was
never needed, and doesn't allow the endpoint to be used to retrieve a
csrf token for use with an anonymous POST.

A temporary Django Setting was added to help with the roll-out:
- EDX_DRF_EXTENSIONS[ENABLE_ANONYMOUS_ACCESS_ROLLOUT]
This setting will help manage the rollout of CSRF protection.

Other minor fixes included:
- Updated README to clarify the purpose of the repo.
- Added testing of the existing csrf app to tox.

ARCH-1269

2.4.2: Add toggle to determine whether to set request.user.

Although setting the `request.user` during `process_view` worked to
solve ARCH-1197 in ecommerce, it introduced an OOM bug in edx-platform.

This introduces a temporary toggle using a Django Setting so that the
fix can remain in ecommerce without affecting other IDAs like
edx-platform.

Once ARCH-1199 is complete and the issue is fixed, it is expected that
this toggle will be removed.

ARCH-1210

2.4.1: request.user set in JwtAuthCookieMiddleware

JWT cookie authentication uses DRF, which does not set `request.user`
until the Middleware call: `process_response`.  This change sets the
`request.user` in process_view, which happens after all
`process_request` calls.

This is has been added to the existing `JwtAuthCookieMiddleware`.

ARCH-1197

add JwtRedirectToLoginIfUnauthenticatedMiddleware

Middleware enables the DRF JwtAuthentication authentication class for
endpoints using the LoginRedirectIfUnauthenticated permission class.

Enables a DRF view to redirect the user to login when they are
unauthenticated. It automatically enables JWT-cookie-based
authentication by setting the USE_JWT_COOKIE_HEADER for endpoints
using the LoginRedirectIfUnauthenticated permission.

This can be used to convert a plain Django view using @login_required
into a DRF APIView, which is useful to enable our DRF JwtAuthentication
class.

NOTE: This includes a breaking change that is unlikely to affect anyone
unless they subclassed JwtAuthCookieMiddleware, which switched from
using process_request to process_view so it would not run before
this new middleware.

ARCH-1051

Reduce level of log messaging

(PROD-505) Update warning to info

Update warning to info message as this case is handled automatically by the system

Allow specifying JWT claims to merge

2.3.7

Fix version number

Version 2.3.2 was released without bumping its version number. This fixes that.