Handle Yjs awareness on the widget comm

[gjmooney]

This PR wires up pycrdt Awareness, so the kernel can consume YMessageType.AWARENESS frames.

CommProvider creates an Awareness(ydoc) alongside sync/update handling. Inbound messages whose first byte is YMessageType.AWARENESS are decoded with read_message and applied with apply_awareness_update.

CommWidget exposes awareness, plus on_awareness_change / unobserve_awareness as thin wrappers over Awareness.observe / unobserve for notebooks and library code.

[martinRenou]

Maybe pin pytest=8 for now so that the CI passes

[davidbrochart]

I think it requires rethinking the async fixtures, I can look at it.

[davidbrochart]

Thanks @gjmooney. We'll need a test for the new functionality.

[davidbrochart]

I think that there is too much mocking in the tests, in the end they don't test much.
Could you try and test more with less mocking?

[davidbrochart]

I think that there is too much mocking in the tests, in the end they don't test much. Could you try and test more with less mocking?

@gjmooney Don't worry if you cannot reach full coverage. I'm fine with no test and explicit # pragma: nocover in the code. In the end it's an optional feature that should not break existing code.

[davidbrochart]

There is something I don't understand: your CommWidget will receive and apply awareness updates, but how are you going to set the awareness and send the updates from the kernel?

[martinRenou]

but how are you going to set the awareness and send the updates from the kernel?

For now setting the awareness from the kernel has not been evoked on our side. I wonder if that is something we want to do?

[davidbrochart]

Isn't test_remote_manager_applies_awareness_messages doing just that? I suggest to remove it then.

[davidbrochart]

Thanks @gjmooney!

[davidbrochart]

Just a note for the future: could you fork the repo and make a PR from there instead of creating a branch here?