Defer rootfs release until after infrastructure teardown
Defer rootfs release until after infrastructure teardown

Tearing down infrastructure in parallel with release process has
unintended side-effects because another rootfs build is started
tentatively when the release process updates the CVE list with
the newly built rootfs version. If the build that was triggered
happens to generate a non-zero receipt diff then it will be promoted
to deploy & test, which can happen interleaved with teardown jobs
from the prior build.

Rather than introduce a pool resource with a lock that would need
to be managed, deferring the rootfs release until infrastructure
teardown avoids that cost at the expense of adding the teardown
time (approx 15mins) to the release cycle.

Signed-off-by: Sam Coward <f2d9ddb83d985bcf331a113cd487aeceb5e618e4@pivotal.io>

cloudfoundry/buildpacks-ci,cloudfoundry/buildpacks-ci,cloudfoundry/buildpacks-ci,cloudfoundry/buildpacks-ci,cloudfoundry/buildpacks-ci