connection: Don't write past the end of the connection buffer

If a message was too big to fit in the connection buffer, the code
in wl_buffer_put would just write past the end of it.

I haven't seen any real world use case that would trigger this bug, but
it was possible to trigger it by sending a long enough string to the
wl_data_source.offer request.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=69267
connection: fix a format string typo in error message
test: Add test showing blocking problem when updating timers

I've noticed a blocking problem in Wayland's event-loop code when updating
timer event sources. The problem occurs if you update the timer at a point
after is has expired, but before it has been dispatched, i.e. from an event
callback that happens during the same epoll wakeup.

When the timer is subsequently dispatched, wl_event_source_timer_dispatch
blocks for the duration of the new timeout in its call to read() from the
timer fd (which is the expected behaviour according to the man page for
timerfd_settime).

This isn't too uncommon a scenario - for example, a socket with an associated
timeout timer. You'd typically want to update the timer when reading from the
socket. This is how I noticed the issue, since I was setting a timeout of
1 minute, and saw my server blocking for this duration!

The following patch adds a (currently failing) test case to Wayland's
event-loop-test.c. It demonstrates the problem using two timers, which are
set to expire at the same time. The first timer to receive its expiry
callback updates the other timer with a much larger timeout, which then
causes the test to block for this timeout before calling the second timer's
callback.

As for a fix, I'm not so sure (which is why I thought I'd post the failing
test case first to show what I mean). I notice that it doesn't actually do
anything with the value read from the timerfd socket, which gives the number
of times the timer expired since the last read, or when the timer was last
updated (which blocks if the timer hasn't yet expired). I believe this value
should always read as 1 anyway, since we don't use periodic timers.

A simple fix would be to use the TFD_NONBLOCK option when creating the
timerfd, ensuring that the read call won't block. We'd then have to ignore
the case when the read returns EAGAIN.
Use non-blocking timerfd to prevent blocking when updating timer event sources

This implements a simple fix for the blocking problem that occurs when
updating a timer event source after the timer expires, but before its
callback is dispatched. This can happen when another event happens during the
same epoll wakeup as the timer event, and causes the read() call in
wl_event_source_timer_dispatch() to block for the updated duration of the
timer.

We never want this read() call to block, so I believe it makes sense for the
timerfd to be non-blocking, and we simply ignore the case where the read fails
with EAGAIN. We still report all other errors as before, and still ignore the
actual value read from the socket.

With this change, the event_loop_timer_updates unit test case I submitted
previously now passes, and weston appears to work as before.