Verify deployments

[mmarchetti]

When deploying an app/api, access the app's direct URL at the end of deployment to verify that the app can start up successfully. Connect does not start a worker until there's an access, unless MinWorkers > 0.

When performing that access, tolerate certain HTTP errors - for example, the / endpoint in an API might expect a POST rather than a GET, or might expect parameters that aren't provided. But if you get back a 5xx code, that indicates a problem.

Also provide a --no-verify flag to allow opting out of this new behavior.

[aronatkins]

For some types of content, e.g. Shiny applications, receiving an initial load of the HTML content will mark that the target worker is likely to receive a subsequent SockJS (websocket) request. Therefore, that session is regarded as alive and could prevent additional connections from being targeted to that worker. Additionally, the presence of a real connection could cause us to preemptively start additional workers.

These factors do not mean that we cannot verify deployments, but are side-effects that folks should understand when testing/using the feature.

Early version of Connect started a worker as a consequence of an application deploy, but that was wasteful for automated deployments, and we offered no opt-out option. Having the client optionally visit the content feels like a more flexible option.