feat: compatibility with BatchGetJobEntity API changes for jobRunAsUser

[jusiskin]

What was the problem/requirement? (What/Why)

The BatchGetJobEntity API response shape is changing. Specifically when the response contains "jobDetails" entities, the "jobRunAsUser" field will return a "runAs" field. For example:

{
  "entities": [
    {
      "jobDetails": {
        // ...
        "jobRunAsUser": {
          "posix": {
            "user": "myuser",
            "group": "myuser"
          },
          // New field below
          "runAs": "QUEUE_CONFIGURED_USER",
        }
        // ...
      }
    }
  ]
}

or if the job's queue has no queue configured user:

{
  "entities": [
    {
      "jobDetails": {
        // ...
        "jobRunAsUser": {
          // New field below
          "runAs": "WORKER_AGENT_USER",
        }
        // ...
      }
    }
  ]
}

This API change has not been deployed in the service yet. We need the worker agent to accomodate
the current API shape and the future API shape (forwards/backwards compatibility).

What was the solution? (How)

Updated the code to accomodate the future API change while still working with the current API
responses.

I've also updated some of the related developer scripts for testing this including the POSIX Docker
containers and the scripts to create service resources.

What is the impact of this change?

• The Worker Agent is backwards/forwards compatible with the BatchGetJobEntity API changes that
  are about to land
• Worker Agent developers can use the developer scripting for testing the Worker Agent's
  functional code that uses the queue jobRunAsUser feature.

How was this change tested?

"backwards" compatibility testing

Ran the Worker Agent integration tests, which assert that the jobRunAsUser worker agent
functionality works against the current service API responses.

"forwards" compatibility testing

• Modified the scripts/create_service_resources.sh script to add the "runAs" when creating queues.
  This is now required in order to create a queue-fleet association, otherwise the API returns
  validation errors
• Added a new POSIX testing container. This is similar to the posix_local_multiuser container
  except that the job user is not overridden

Used the src/deadline_worker_agent/boto/shim.py to mutate the API responses and return the new
API shape (includes the "runAs" field in the BatchGetJobEntity API responses).

I've also updated the unit tests to test both forwards and backwards compatibility.

Was this change documented?

No

Is this a breaking change?

No

[AWS-Samuel]

If posix isn't in the job_run_as_user_data, I think we get a KeyError here

[jusiskin]

Good eye! I think that code path should not reachable because of earlier input validation:

https://github.com/casillas2/deadline-cloud-worker-agent/blob/40fcd7c7f5c3236a00c69e7535bfc662c9b76892/src/deadline_worker_agent/sessions/job_entities/job_details.py#L328-L331

Regardless, I have made this code more defensive in case someone accidentally changes/removes the validation code or my assumption is incorrect.

[AWS-Samuel]

Nit, I think we're trying to refrain from using invalid and to use non valid whenever possible. Applies elsewhere in this file

[jusiskin]

Thanks for pointing this out. I've replaced all instances of invalid → nonvalid in the repo.