Fix project upload auto-deploy race condition

[brandenrodgers]

Description and Context

This fixes a race condition in the way that we handle project autodeploys. Currently, our backend will skip the autodeploy for a successful build if there is another build currently in progress for that same project.

You can easily reproduce this by:

1. Opening two terminal windows, both with the same project and target HubSpot account
2. Run hs project upload in both windows at the same time (within a second or two should be enough)

This should result in the first window hanging on the "build succeeded" step indefinitely. The second instance should build and deploy as expected.

I fixed this by breaking out the polling for the auto deploy information into its own dedicated step. Now, the build polling logic will exit as soon as the build status is either success or failure. At that point we'll check to see if we need to poll for auto deploy information. From my testing, the autodeploy information is usually immediately available so we never have to poll for it. There are some edge cases, like the one I explained above, that can cause the auto deploy info to not be available. That's where this logic kicks in. We'll poll for auto-deploy information for a minute and then we'll gracefully exit if it never becomes available.

Screenshots

This is what will log to the user if the auto deploy information never becomes available

TODO

Who to Notify

[camden11]

LGTM + tested and works. Only thing I would suggest is maybe making the polling time a bit shorter? First time I tested I wasn't sure it was working. But I guess better safe than sorry there

[brandenrodgers]

Good call @camden11. I asked the BE team and they said 30s would be reasonable. If the deploy info isn't available by then, then it'll never be available.