Revert "Revert "Enable load balancer slow start"" - #51418

Reverts #51253

Our previous attempt to deploy this change - #51105 - failed because we were using an incompatible load balancing algorithm. Re-attempting this change.

Enable a 300 second slow start (successfully tested via manual configuration change in production) to reduce the likelihood of performance issues when releasing to production during peak usage time periods. Switch load balancing algorithms (something we've tested manually in production during peak usage to ensure no impact on performance) because we were using an algorithm that is incompatible with Slow Start.

https://codedotorg.atlassian.net/browse/INF-864

Testing story

Our managed test environment provisions a load balancer, but does not have an Auto Scaling Group implemented, so no new "Front End" (web application server) EC2 Instances will be provisioned on our managed test server when this change reaches that environment, so this feature will not be exercised until it reaches production.

We could provision an adhoc with the Full Stack (auto scaling, load balancer, RDS database, etc.) enabled, but we have not been successful in getting those to provision lately, and also if we pushed a new commit to this feature branch to simulate a production release, a longstanding limitation in our adhoc provisioning logic, we re-provision the entire stack as a single EC2 Instance environment (no CloudFront, no load balancer, no auto scaling group, no RDS cluster, etc.).

Tested in production via manual configuration change. In one case, 300 second Slow Start period resulted in a release to production during peak usage where there was NO performance degradation. With 120 seconds Slow Start period, there was at least one deploy where performance deteriorated during new application server launch. See notes in Slack.

Deployment strategy

Possibly release as a 2nd production deploy later in the work day to minimize risk.

Follow-up work

Privacy

Security

Caching

PR Checklist:

• Tests provide adequate coverage
• Privacy and Security impacts have been assessed
• Code is well-commented
• New features are translatable or updates will not break translations
• Relevant documentation has been added or updated
• User impact is well-understood and desirable
• Pull Request is labeled appropriately
• Follow-up work items (including potential tech debt) are tracked and linked