Remove retrying of pack builder create

[edmorley]

Since:

• The retry handling is broken, such that if the command fails after three retries, then the exit code is obscured and the CI run continues to the next step. This causes a confusing error message that's shown instead of the actual error.
• In the case of legitimate failures, the retries prolong the time until the CI result shows the failure.
• The builder creation step is pretty reliable now (I've inspected several dozen invocations and didn't see any failures).
• If we start seeing intermittency in the future, I would rather know about it so we can improve reliability for everyone, rather than cover it up via retries.

GUS-W-11263169.

[edmorley]

I should note a few weeks ago I also scaled up cnb-shim from one web dyno to two, plus enabled preboot -- to reduce chance of cnb-shim related errors during builder creation (or when people use it via --buildpacks).

[joshwlewis]

This may have also been helped by the go rewrite @jason-salesforce did.

[edmorley]

Ah true! :-)

I'm presuming some other failure modes are errors or rate limits pulling from Docker Hub and/or ECR. However Circle CI now has exemption from Docker Hub rate limits even when not authed (I think there was a spell before that was implemented), and the ECR rate limit doesn't seem to be an issue in practice (whilst the limit is low, it's per Docker repo per IP, and unlike the buildpack cutlass tests, this CI doesn't do repeat pulls of the same Docker repo within the same job).

[edmorley]

(And if we hit rate ECR limits again in the future, perhaps it's another reason to switch back to Docker Hub from ECR for our buildpack images.)