Timing problem in service_invocation quickstarts

One timing problem that occurred when I ran the javascript/http example as a multi-run app in the devcontainer:

The order-processor may not be ready to receive the first order from the checkout service, in which case the first post returns a 500 and exits the checkout loop.

Moving the sleep to the top of the loop helps.

I think this problem and potential improvement applies to all of these multi-run service_invocation implementations, not just javascript.

Is there a better way for checkout to wait until the order-processor is running?

_Originally posted by @joebowbeer in https://github.com/dapr/quickstarts/issues/536#issuecomment-2246867640_

Start by running the javascript/http service_invocation example as a multi-run app in the devcontainer, then inspect the checkout loop and its startup timing. Compare the other multi-run service_invocation implementations and determine whether moving the sleep or using a readiness wait prevents the first POST from returning 500 and ending the loop.

Written by the indexing model from the issue text.