onChange should update instead of sync

[EugeneZ]

When a document changes, the Redis extension performs a full re-sync exchange with every single other server in the cluster. This is way more expensive than just sending an update.

[ralphiee22]

I don't think redis guarantees message delivery which makes me worry about this change.
If messages are dropped then there will be updates that are missed by other clients.
I think that is part of the safe option of sending the entire document each time that if a single update is missed, then on a subsequent sync it will still have the full change set.

[ralphiee22]

If we want to change the system to only emit single change events, then we probably need to re-architect to use something like redis-streams, where we can more reliably confirm that a client receives emitted messages

[EugeneZ]

Good point, did not think about that. It seems that doing a full sync only partially helps, though. If there is a problem with receiving messages, it can affect a full sync, too, right? Definitely okay with closing this PR if y'all think it's worth the tradeoff, but it just seems counter to the idea of YJS efficiency.

[ralphiee22]

I think @janthurau could speak more to why this implementation was chosen

[janthurau]

Thanks for your PR @EugeneZ! Will check this out next week.

In general it seems better to send the update messages, I'm just not sure what happens on newly connected redis clients, or if that still works if an update message gets lost (as raised by the @ralphiee22). An option could be to implement a simple counter field. If the counter-1 doesn't match previously received update event, the server could request a full sync again.