Consider parameterizing allow_major_version_upgrade

[rbreslow]

If you try to upgrade the major version of a DB instance via Terraform, the apply operation will fail like:

Error: Error modifying DB Instance districtbuilder-staging: InvalidParameterCombination: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.
        status code: 400, request id: 299dedfe-4b1e-4746-8b2a-5c562d9f8c89

The AWS docs don't rule out the possibility of modifying the DB engine via Terraform:

For major version upgrades, you must manually modify the DB engine version through the AWS Management Console, AWS CLI, or RDS API. For minor version upgrades, you can manually modify the engine version, or you can choose to enable auto minor version upgrades.

Paired with the use of name_prefix for the DB parameter group (PublicMapping/districtbuilder#478), we could have Terraform perform an entire major version upgrade. This would eliminate the need for us to ensure a parameter group exists and thread it through between version hops, freeing up more mental bandwidth for monitoring the upgrade process.

I could see us leaving this variable set to false when business is usual, but we set it to true when performing the upgrade.

See: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/db_instance#allow_major_version_upgrade

[hectcastro]

I think the main reason this wasn't added before is because we'd still need to conditionally set apply_immediately. My understanding is that with just allow_major_version_upgrade = true, the major version upgrade would get queued for the next maintenance period, which is undesirable for us because we want to be standing by when the major upgrades occur.

[rbreslow]

I could see us parameterizing both and setting them both to true when we're ready to upgrade. The way things are now, we still need to modify the tfvars file to reconcile the engine version, so I don't think this results in any net positive work.