perf: ⚡️ run apply namespaces in apply pipeline concurrently

[jaskaransarkaria]

Continue chunking and batching namespaces across different pipelines but within those pipelines run the applies concurrently.

This PR covers:

• if the pipeline fails a namespace apply, then fail silently but collect all the errored namespaces and log them so we can inspect them if we need
• rewrite the namespace apply so we can take advantage of go routines and speed up apply pipelines
• remove duplicate call to plan
• explicitly pass a namespace arg to destroyNamespace, planNamespace and applyNamespace to fix a bug where incorrectly structs were accessed during parallel runs
• move contains fn from deleteutils to util
• project test coverage increased from 68.5% -> 72.0%

performance results:

https://concourse.cloud-platform.service.justice.gov.uk/teams/main/pipelines/environments-live/jobs/apply-namespace-parallel-test/builds/2 (one errored namespace can be found at the bottom of the log)

duration	34m 43s Which cuts the build time in more than half (compared to the same run on current apply live 1h 20m)

build peaked (running on worker-3) Another apply pipeline was running at the same time on the same worker, but another was running on worker 1 at the same time

concourse-worker-0               19m          3170Mi
concourse-worker-1               18m          5180Mi
concourse-worker-2               566m         3791Mi
concourse-worker-3               3418m        5885Mi

Note current pod limits are (if we raise the limits go will utilise those extra resources):

    Limits:
      cpu:     4
      memory:  8Gi
    Requests:
      cpu:     1
      memory:  1Gi

[jaskaransarkaria]

duplicated plan see line 152 above

[jaskaransarkaria]

close the channel which cascades down through the child go routines and in turn closes them to prevent memory leaks

[jaskaransarkaria]

convert array into a channel

[jaskaransarkaria]

combine multiple channel results back into a single channel

[jaskaransarkaria]

In a new go routine run each apply for each namespace

[jaskaransarkaria]

run as many go routines as we have cores, this proves to be a conservative number of routines because of how lightweight and cheap they are. We should monitor performance in concourse and adjust here if necessary.