backend/sys/client: Use unbounded buffering, with a test case

[ids1024]

To match the behavior of libwayland-client, we should default to unbounded buffers; while servers should only use bounded buffers.

I'm not sure why using roundtrip() gets WouldBlock with client_system,server_system, but not with just client_system...

[ids1024]

Hm, FreeBSD failing with:

cargo test --workspace --exclude wayland-tests
Segmentation fault (core dumped)

Given the --exclude, I guess that's a non-deterministic thing unrelated to this change, but not reassuring...

[ids1024]

I guess we should have tests for both in_data and out_data buffering.

[ids1024]

CI is hanging on this test in client_system? Not happening locally...

I guess an issue with how the test is written, rather than the rs backend change here. Or a different issue in the sys backend...

[ids1024]

It looks like in_data can't be filled, I guess unless a single message were too large?

dispatch_events() in wayland-backend/src/rs/client_impl/mod.rs calls fill_incoming_buffers() when read_one_message() fails with MissingData or MissingFD. Then it loops and will free spacing in in_data again when read_one_message() is able to parse a Message.

If it's possible for fill_incoming_buffers() to run with in_data already full (maybe possible in a contrived case at least), rcv_msg() will presumably return 0, and then fill_incoming_buffers() returns Errno::PIPE on that...

[ids1024]

libwayland has #define WL_MAX_MESSAGE_SIZE 4096. I don't know if we match it's behavior, and have tests for that.

[ids1024]

But a in_data buffer larger than WL_MAX_MESSAGE_SIZE should then not be necessary, at least as rs/client_impl currently uses it.

[ids1024]

The test hanging on CI still seems to be an issue. And not a one-off fluke...

(It would be nice to reproduce that locally.)