Make start_update users aware that it's synchronous w/ worker.

[drewhoskins-temporal]

Is your feature request related to a problem? Please describe.

By default, start_update waits until the (often remote) worker accepts it.

It misleads customers into thinking it's fully async, as start_activity and start_workflow are. Customers won’t be aware that the remote worker blocks this call and might inadvertently take a dependency on a worker, for example, that has a lower availability level than the service calling it. Such a mistake would cause an outage to a critical service.

In the future, we want users to be able to choose durable-on-admitted. Removing the default here would make space for that.

Describe the solution you'd like

We decided to force customers to explicitly pass in a flag saying what’s being awaited. (e.g. start_update(wait_for_stage=ACCEPTED/COMPLETED)) and then if they don’t provide it.
We should also make sure the comments are clear that the remote worker must be present for the operation to work.

Additional context

Per-SDK Tickets

• Go - Clarify waiting semantics for UpdateWorkflow sdk-go#1449
• Java - Make startUpdate users aware that it's synchronous w/ worker sdk-java#2045
• Core -
• TypeScript - [Feature Request] Make startUpdate users aware that it's synchronous w/ worker sdk-typescript#1403
• Python - [Feature Request] Make start_update users aware that it's synchronous w/ worker sdk-python#514
• .NET - [Feature Request] Make StartUpdateAsync users aware that it's synchronous w/ worker.  sdk-dotnet#231
• PHP - [Feature Request] Make startUpdate users aware that it's synchronous w/ worker sdk-php#426
• Temporal CLI - [Feature Request] Start Update should require a wait stage. cli#597

[cretz]

Or force customers to explicitly pass in a flag saying what’s being awaited

I like this required-wait-stage approach and we can remove the requirement and default to durable on-admitted if/when it becomes available. If there's no objection from others, would love to make this the way in all SDKs

There is a set of pending work for updates in SDKs once internal metering is improved that this work can be a part of. This issue, #431, and #432 should all be knocked out by each SDK (some are already done).