Ingest batcher can lose data if the lambda terminates at the wrong time, or ingest fails

### Description / Background

As files are submitted to the ingest batcher, it runs periodically and assigns files to ingest/bulk import jobs.

When it assigns files to a job, it first updates a DynamoDB table to assign them to the job, then it sends the job to the ingest system via SQS. If the lambda that does this happened to be terminated after it updated DynamoDB but before it sent the job to SQS, those files would never be included in a real job, as they are already assigned to the job that was not sent.

### Steps to reproduce

1. Submit enough files to the ingest batcher to produce a job
2. Terminate the ingest batcher lambda after it has assigned files to the job but before it has sent it
3. See the files are never sent in any ingest or bulk import job

### Expected behaviour

The files should be ingested eventually. It still should be impossible for the files to be ingested more than once.

### Technical Notes / Implementation Details

This happens in IngestBatcher.

We probably won't want to change how the files are assigned, because the DynamoDB update prevents us from ever sending the files for ingest more than once, and creating duplicate data.

We could introduce a component to watch the ingest process via the job tracker, notice when the job never gets to the ingest system, and unassign the files from the job in the batcher.

We might not want to unassign files from a job if the job fails, because it could be a problem with the data in the files. At the same time, it could just be one of the files that has a problem. We could think about a process to handle this, but it's not clear if we can solve that problem.

This is also related to:
- https://github.com/gchq/sleeper/issues/930

Any approach to atomic ingest is likely to affect this. It might be better to think about this in that context.