Add panoptes-production-sidekiq-alt pod type

[lcjohnso]

To address high latency in lower priority queues while UserSeenSubjectsWorker jobs in data_high are dominating available threads, this PR adds a single dedicated pod that will service the default (most important), data_medium, and data_low queues. This change adds an additional pod to the minimum total number of pods, but this cost makes sense in the short term (i.e., while panoptes replica DB is out of service during migration).

[lcjohnso]

On hold for now due to more aggressive autoscaling resolving backups w/o need for queue-specialized pods.

[yuenmichelle1]

Approving and merging. Issue is still happening. Will create a write up on Slack thread.

Essentially: UserSeenSubjectsWorker hits a connection timeout on the update transaction. This leads to potential data locking. Not only that but UserSeenSubjectsWorker is set to retry (I believe until success), which leads to a backup of jobs in queue.

Current theory is that because we shut off our read-replica, even though this query and others do not utilize the read-replica, there are current heavy queries that were using read-replica that are now sharing resources from production db and making it harder for these smaller transactions to clear through.

However, because these workers are typically fast, CPU never hits threshold of autoscaler until job queue backup hits a really high amount, (by then latency of data_medium and lower priority queues are hours behind).

To mitigate, as Cliff has mentioned, we create a dedicated pod to deal with the lower priority queues. (Data_medium and lower)