watch::Sender::send is a error-prone default

[dpc]

Description

We've recently been banning watch::Sender:send method in our codebases because:

However, when send fails, the value isn’t made available for future receivers (but returned with the SendError).

is a non-obvious behavior that leads to tricky to debug bugs.

From my PoV it's very natural to use a watch channel as a "latest value with an ability to wait for updates", andsend name does not immediately point to the trickiness of behavior of "dropping updates" in it. Yes, the returned result should nudge the user to "why is there a possibility of an error, and what happens in this situation", but in practice it has been missed multiple times, and it's quite common in other channels to do let _ = tx.send(); because dropping messages when no one listens doesn't matter for them because how they are used they don't have state that would matter for subscribes that join later. And when one looks at tx they can't immediately tell what channel is it, so they simply won't notice this is a watch::Sender and dropped message might actually matter a lot.

send_replace's behavior seems much more safer default, and therefore (IMO) better candidate for a default (shortest name). But I could accept someone disagreeing with. Possibly there should not be a send at all, and current send should be renamed to send_xyz (send_and_update_if_connected?) to bring to the user's attention that they should consider alternatives and details between them.

[Darksonn]

I'm not entirely happy with the watch channel, but we can't remove or rename methods due to backwards compatibility.

[maan2003]

but we can still mark it as depreciated, IMO it is bad enough to deserve that.