DRAFT django modernization

[annamontare-nava]

What needs to happen to get this ready for review:

• add validators for marked fields
• resolve remaining todos
• why is jenkins failing?
• make sure unit tests pass
• make sure jenkins passes
• makemigrations
• apply the migrations locally
• see that database fields are updated
• check databases in various environments to make sure the new validators won't break anything
• add tests?
• how do I know if migrations should be performed before or after deploying code?

JIRA Ticket:
epic: BB2-4543

What Does This PR Do?

Changes to Django models to migrate CharField's to TextField's, make max_length settings consistent with specs, and align validators across fields.

Also, fix a doc comment and remove duplicate code.

I did not include Ruff changes to hopefully make this easier to review.

What Should Reviewers Watch For?

If you're reviewing this PR, please check for these things in particular:

• Any tests we should do to ensure that the new validation doesn't break existing records?
• For some fields, the previous max_length seemed to match what oauth2_provider had for max_length, but not the actual length of the values. I changed them to match the actual length, and left a note, but would we prefer having them match what's in oauth2_provider?
• Should state fields still have a max_length?
• should I squash migrations before the merge?
• Are there any other changes I need to make to go along with this?

For fields that are URLs, I chose to make all of them TextField's with URLValidator's and an explicit max_length of 2048. Counterproposals:
- Make all URLs URLField's. Pros: uses the tools Django provides, arguably what a new person to the project might expect the fields to be. Cons: Is a CharField subclass; there have been issues with the default max_length in the past, so we'd have to set a larger one.
- Make a subclass of TextField that includes the validator and our chosen max_length, and make all URLs use that. Pros: It's a TextField, codifies the consistent handling of URLs across models. Cons: might still be easy to forget in new code.

• Is there a preference for either of these options?
• Did I forget to convert any URLs?
• Do we want to ensure only https for any/all urls?
• Noticed that a lot of fields are named "uri" when it might be more specific to say "url". I assume this would not be worth changing?

Validation

• Apply migrations, run locally, and ensure the database fields have updated to the correct type

What Security Implications Does This PR Have?

Please indicate if this PR does any of the following:

• Adds any new software dependencies
• Modifies any security controls
• Adds new transmission or storage of data
• Any other changes that could possibly affect security?

• Yes, one or more of the above security implications apply. This PR must not be merged without the ISSO or team
  security engineer's approval.

Any Migrations?

• Yes, there are migrations
  • The migrations should be run PRIOR to the code being deployed
  • The migrations should be run AFTER the code is deployed
  • There is a more complicated migration plan (downtime,
    etc)
• No migrations

[annamontare-nava]

Noticed that a lot of fields are named "uri" when it might be more specific to say "url". I assume this would not be worth changing?

[JamesDemeryNava]

@annamontare-nava what is the latest here? Will this branch be picked up again in the future?

[annamontare-nava]

@annamontare-nava what is the latest here? Will this branch be picked up again in the future?

I think Jimmy suggested I prioritize other work, so haven't worked on it in a bit, but I'd like to pick it up in the future and finish the work.