create a valid startup command for both new worker types `api-worker-…

[rparke]

…jobs-saveandapi-worker-jobs-save-documents`

when adding the new queues and new worker types https://github.com/alphagov/notifications-aws/pull/2884 we need to ensure that new workers can startup properly without any issues. This means temporarily configuring each new worker type to take tasks from existing queues, before upgrading notifications-api #4784 to populate, and take messages off the new queues.

TODO:

• Add Valid Startup Command
• New queue and worker
• Add new argument has_documents to shatter-job-rows task
• Call shatter-job-rows task with has_documents argument

[risicle]

My only concern with this is there will be a phase of the rollout where the jobs worker(s) will be able to create notifications at 3x the current rate (3 pools cooperating). Remember, the main reason for limitations on numbers of jobs workers is to throttle this rate.

Hopefully that will be a short period and this won't be a problem?

[rparke]

My only concern with this is there will be a phase of the rollout where the jobs worker(s) will be able to create notifications at 3x the current rate (3 pools cooperating). Remember, the main reason for limitations on numbers of jobs workers is to throttle this rate.

Hopefully that will be a short period and this won't be a problem?

That's basically my assumption. The alternative is maybe that we initially initialise those workers to do nothing? So they can start up but nothing happens

[risicle]

Mnah we probably want to them to do something in case somehow we break the original. It's probably fine, let's just not hang around when we do it.

[rparke]

Mnah we probably want to them to do something in case somehow we break the original. It's probably fine, let's just not hang around when we do it.

Works for me. I guess queue all 3 releases up to go as quickly as posible