BB2-3243: Add --all option to update_access_grants Django command

[loganbertram]

JIRA Ticket:
BB2-3243

User Story or Bug Summary:
We have switched all Sandbox apps over to 13-month category. However, any existing (synthetic) access grants won't have an end date to them unless we run a script to update those. This task is to create and run a script to update all EXISTING access grants so they have an end date, 13 months from the date of the script running.

What Does This PR Do?

Addresses the need to apply access grant updates to all applications.

What Should Reviewers Watch For?

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

• Locally run the script with various kinds of access grants

What Security Implications Does This PR Have?

Submitters should complete the following questionnaire:

• If the answer to any of the questions below is Yes, then here's a link to the associated Security Impact Assessment (SIA), security checklist, or other similar document in Confluence: N/A.
  • Does this PR add any new software dependencies? No.
  • Does this PR modify or invalidate any of our security controls? No.
  • Does this PR store or transmit data that was not stored or transmitted before? No.
• If the answer to any of the questions below is Yes, then please add a Security Engineer and ISSO as a reviewer, and note that this PR should not be merged unless/until he also approves it.
  • Do you think this PR requires additional review of its security implications for other reasons? No.

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

Submitter Checklist

I have gone through and verified that...:

• This PR is reasonably limited in scope, to help ensure that:
  1. It doesn't unnecessarily tie a bunch of disparate features, fixes, refactorings, etc. together.
  2. There isn't too much of a burden on reviewers.
  3. Any problems it causes have a small "blast radius".
  4. It'll be easier to rollback if that becomes necessary.
• I have named this PR and its branch such that they'll be automatically be linked to the (most) relevant Jira issue, per: https://confluence.atlassian.com/adminjiracloud/integrating-with-development-tools-776636216.html.
• This PR includes any required documentation changes, including README updates and changelog / release notes entries.
• All new and modified code is appropriately commented, such that the what and why of its design would be reasonably clear to engineers, preferably ones unfamiliar with the project.
• All tech debt and/or shortcomings introduced by this PR are detailed in TODO and/or FIXME comments, which include a JIRA ticket ID for any items that require urgent attention.
• Reviews are requested from both:
  • At least two other engineers on this project, at least one of whom is a senior engineer or owns the relevant component(s) here.
  • Any relevant engineers on other projects (e.g. BFD, SLS, etc.).
• Any deviations from the other policies in the DASG Engineering Standards are specifically called out in this PR, above.
  • Please review the standards every few months to ensure you're familiar with them.

[jimmyfagan]

Looks good! Will want to discuss some testing results and maybe try to use this in the TEST environment before moving to SANDBOX, but great job leveraging the existing script to make this work so simply!

[jimmyfagan]

Instead of superseding --all, it might be clearer to have the two options be mutually exclusive. Optional, just an idea!

[loganbertram]

If we were introducing outside our team I probably would, lol. I may still! I thought that for us and future internal teams, the help string would make it make sense and defaulting to the less destructive option would at least limit accidents.

[jimmyfagan]

Is this an accidental extra new line, or is this an automatic formatter thing?

[loganbertram]

Purposeful to match PEP 8 standard on spacing around class declarations. We should get the team using PEP 8 tools in their IDE. I fix a lot of stuff like this reflexively when I see it because PyCharm yells at me if its not to the standard.

[loganbertram]

I'm pretty sure the django orm compiles very similar sql with this pattern to if i iterated over the queryset directly below. I think this way is more readable, but may shuffle the whole thing to make the options mutually exclusive.