Ensure we call operation on the most recent view

[Ph4ntomas]

problem: it's possible for operate() call to apply on a stale view if a view is pending, leading to some operation failing.

solution: There are two part of this fix:

1. Enforce ordering of update and operate message by using the message queue used by message
2. Delay sending operate calls to the server until after the view was sent.

Fixes: #443

[Ph4ntomas]

Okay this works as far as I can tell, but I need to check/implement the lua side

[Ph4ntomas]

I now wonder if I should push this server-side, so it doesn't requires client-side tricks

[Ph4ntomas]

I now wonder if I should push this server-side, so it doesn't requires client-side tricks

Okay, so I did explore that route a bit, but came upon the following issue:

• server side has no idea what's the client side is doing:
  When an update comes from the client-side only (i.e. config generated messages), the server is not aware of that until after the client-side is done with its update. We could request a view, but we have no way of knowing that will be handled before the update ends.
• While operation don't currently return anything, they do in iced and moving synchronization server-side would make it harder to deal with. The client side implementation only requires a callback that would be called with whatever the RPC call return.

On the other hand, fixing ordering in lua the same way it was done in rust only required yield-able stream/channels. Those can be built from cqueues's promise and/or conditional variables, as cqueues is coroutine-based (no two coroutine runs at the same time) I went with a simple "spsc"-ish channel.
The implementation is pretty bare (an unbounded channel) and the channel sender is shared amongst all event source, but we don't need to synchronize the calls anyway and I did not see the point in doing anything fancier that we'd have to maintain.

[Ph4ntomas]

Some notes:
It may be possible to reduce the amount of view request we send. I don't think it should go here.

The way I see it, two improvements could be done:

• Don't call the request view RPC if one was sent and the new tree hasn't yet been sent
• Pool client-side message together, and handle them when the server sends its (potentially empty) event list as a reply to the view request.

I'm not doing that here, as I don't really see any need for it at the moment.