Use oauth toolkit's `ALLOW_URI_WILDCARDS` instead of a custom `Application` model

[mvandenburgh]

Prerequisite to this issue: #1826

django-oauth-toolkit now supports wildcard redirect URIs - https://django-oauth-toolkit.readthedocs.io/en/latest/settings.html#allow-uri-wildcards. We should drop the custom Application model we've defined to allow staging deploy previews to work (https://github.com/dandi/dandi-archive/blob/master/dandiapi/api/models/oauth.py#L10), and switch to this.

[mvandenburgh]

Reopening due to revert #2338

[dandibot]

🚀 Issue was released in v0.8.0 🚀

[mvandenburgh]

Here's a more detailed description of what exactly happened here/why this was closed and then reopened.

Background
Years ago, we wanted to enable Netlify deploy previews on pull requests. Since we use oauth for login, we must specify a list of allowed redirect URIs that are valid for the oauth flow. Since Netlify deploy preview URLs are variable, this presented a problem - django-oauth-toolkit allows for one or more redirect URIs to be specified, but it did not support anything besides exact text matching. That is, regex or wildcard matching were not supported. However, django-oauth-toolkit does allow for downstream projects to override its Application model (https://django-oauth-toolkit.readthedocs.io/en/latest/advanced_topics.html#extending-the-application-model) (i.e. the Django model representing the DB table that contains the info for oauth2, including redirect URIs and the validation logic for them). We used this to override the Application model in order to support wildcards for Netlify deploy previews (see dandi-archive PR #353. Note the redirect_uri_allowed method on the StagingApplication model there). There were some challenges to getting this working properly, largely due to it using an undocumented feature of Django called “swappable models” (https://stackoverflow.com/questions/22025476/what-is-swappable-in-model-meta-for) and required us to do some extensive manipulation of the DB migrations. This has been deployed since 2021 and has worked for us since then.

Now
This approach has worked fine for years, but recently django-oauth-toolkit added an optional setting that allows for wildcard matching in redirect URIs (https://django-oauth-toolkit.readthedocs.io/en/latest/settings.html#allow-uri-wildcards). Using this would let us drop the custom StagingApplication model and just let django-oauth-toolkit use its built-in Application model. Below is the exact sequence of events that happened on 4/18 when we attempted to deploy this.

1. Unpin django-oauth-toolkit, generate migrations for downstream StagingApplication #2320 unpinned django-oauth-toolkit. We had previously pinned it because a new major release happened that claimed “breaking changes”. After unpinning, we confirmed there were seemingly no breaking changes that affected DANDI, but there were some new columns added to the django-oauth-toolkit Application that needed to be propagated downstream to our custom StagingApplication.
2. The deploy failed due to some pip cache issues on Heroku. Since we just unpinned the dependency, the existing cached 1.x version was still considered valid so Heroku didn’t upgrade it. Require minimum version of 2.0 for django-oauth-toolkit #2326 explicitly required the new version of django-oauth-toolkit and resolved the issue.
3. Once we confirmed that the new version of django-oauth-toolkit worked as expected, I opened Switch staging back to builtin oauth Application #2331 to do the switch to the built in model w/ the new setting that allows for wildcards in redirect URIs. Upon merging, we encountered this error - django.db.utils.ProgrammingError: column oauth2_provider_application.post_logout_redirect_uris does not exist. After some investigation, we figured out that because the built in oauth2_provider_application (i.e. the Application model) was swapped for our custom StagingApplication, all of the new migrations for the Application model from the latest version of django-oauth-toolkit were applied to the StagingApplication instead. The oauth2_provider_application table still existed, but stopped being managed by Django’s migrations framework as soon as we “swapped” the model.
4. To fix the issue in 3), we needed to force Django to apply the relevant migrations to the oauth2_provider_application table, despite the fact that it thought it already applied them. This required going through the upstream migrations manually (https://github.com/jazzband/django-oauth-toolkit/tree/3.0.1/oauth2_provider/migrations) and figuring out which ones touched the Application model. This turned out to be 0006, 0007, 0009, and 0010. We used manage.py migrate –fake to move the migration “pointer” back to the latest migration that was actually last applied to the underlying DB table. This turned out to be migration 0005 for our deployment of DANDI. So, we needed to force Django to apply 0006, 0007, 0009, and 0010, while “faking” 0005 and 0008, 0011, and 0012. This was the exact sequence of commands:

./manage.py migrate oauth2_provider 0005 --fake
./manage.py migrate oauth2_provider 0006
./manage.py migrate oauth2_provider 0007
./manage.py migrate oauth2_provider 0008 --fake
./manage.py migrate oauth2_provider 0009
./manage.py migrate oauth2_provider 0010
./manage.py migrate oauth2_provider 0011 --fake
./manage.py migrate oauth2_provider 0012 --fake

Now that the DB issue was resolved, we proceeded with enabling the redirect URI wildcard support. This turned out to be impossible, since django-oauth-toolkit has not actually released the wildcard support to PyPI yet. It turns out that the django-oauth-toolkit docs are deployed immediately from master, but releases happen much less frequently.

Conclusion
Since the wildcard support wasn’t actually released, we ended up just reverting all the related PRs except for the django-oauth-toolkit dependency upgrade. The current state of dandi-archive master branch is stable and should be deployable with no issues.