EDU-3748: Tweak signal vs update text

[dandavison]

Suggested improvement to signal vs update description:

This was hard to understand:

The clients care more about the latency of sending the message than they do about the latency of the end-to-end operation.

Part of the problem is that no "end-to-end operation" is defined in the case of signal. We don't lose anything by deleting this since the update bullet points make the end-to-end latency point clearly:

The clients want a low-latency end-to-end operation and are willing to wait for it to finish or be validated.

I've replaced it with a bullet reminding users of the important point that they simply do not get a result/error in the case of signal. I think that this change results in bullet points that better communicate the appeal of update, and the continuining role for signal.

[drewhoskins-temporal]

👍 This is fine, the first bullet point mostly covers what I was trying to say in the second point.
One optional note: "don't need a result or exception" is a negative, whereas the others are positive, which adds ambuigity to the logic (is it an or or an and?) and messes with the vibe that update is the default and you actively need a reason to choose signal.
I like being cautious about recommending signal because it swallows unexpected exceptions such as deserialization errors.
We could either cut this bullet point entirely or rephrase as something like "you don't need a result and are okay are willing to 'fire and forget'" to make it sound slightly scarier.

[dandavison]

OK! I'm fine with whatever variant here. I was actually trying to do the same as you -- I thought what I wrote sounded offputting, since a result or exception is a desirable thing. I've changed it to

The clients are willing to "fire and forget": they don't want a result or exception from the message.

The negative "don't want ..." construction there matches the next bullet point about Signal ("don't want to rely on the Worker being available").

There was already a mixture of negative and positive constructions but I wouldn't worry about the coherency from a boolean logic POV; it'll be understood.

[fairlydurable]

Hi @drewhoskins-temporal. Is this PR ready for review and merge? Thanks!

[fairlydurable]

Tech review done.
No docs issues.

Unblocking to move forward.