BatchApiRequestWorkerSpec works! The goal is to port the papiv2 request manager behavior into GCP batch.

We just need to rename the methods to remove the PAPI names.

Now, we just need to fix the runtime errors, wiring the correct messages, etc.

The queue must be cleared after executing the requests.

Abort request handler was returning the wrong message, also, keep the old
behavior where abort request is handled once only.

This grabs many details from PAPIv2, work still pending on the tests.

NOTE: This could break the current integration.

…not in batch

Query the job status to not delete a terminal job.

The execution is now handled by BatchRequestExecutor.

This removes the custom error mappers that detect preemptible errors because these are supposed to be handled natively by GCP.

The requests were being reversed unnecessarily.

There is a failed test which we need to fix, there is no need to run the whole suite for now.

…rSpec

There are a few tests that were marked with TODO notes, still, we found out that
the behavior from batch is the same than the behavior from papiv2, both of these
backends behave differently than papi-common.

This allow us handling the abort result instead of blindly marking the job as aborted.

Now, we look for the submit requests before sending an abort request, canceling jobs that were not submitted to GCP.

Turns out that this is now unnecessary because we are already mapping query errors to a RunStatus.

Turns out that this is now unnecessary because we are already mapping query errors to a RunStatus.

When aborting an individual job, only that job can be aborted instead of
all the jobs from that workflow.

In theory, this solves #7407

Turns out that this is not the correct fix.

- Switch the noisy logs to debug level.
- Remove status codes ported from PAPI because they do not have any usefulness in batch.
- Remove all the test cases involved the PAPI codes.
- Clean RunStatus from the unused args.
- Rename JES occurrences to Batch.