gdbus: Cope with sending fds in a message that takes multiple writes

• gdbus: Cope with sending fds in a message that takes multiple writes

  Suppose we are sending a 5K message with fds (so data->blob points to 5K of data, data->blob_size is 5K, and fd_list is non-null), but the kernel is only accepting up to 4K with each sendmsg().

  The first time we get into write_message_continue_writing(), data->total_written will be 0. We will try to write the entire message, plus the attached file descriptors; or if the stream doesn't support fd-passing (not a socket), we need to fail with "Tried sending a file descriptor on unsupported stream".

  Because the kernel didn't accept the entire message, we come back in. This time, we won't enter the Unix-specific block that involves sending fds, because now data->total_written is 4K, and it would be wrong to try to attach the same fds again. However, we also need to avoid failing with "Tried sending a file descriptor on unsupported stream" in this case. We just want to write out the data of the rest of the message, starting from (blob + total_written) (in this exaple, the last 1K).

  Resolves: #2074 (closed)

• gio/tests/gdbus-peer: Exercise fds attached to a large message

  This incidentally also exercises the intended pattern for sending fds in a D-Bus message: the fd list is meant to contain exactly those fds that are referenced by a handle (type 'h') in the body of the message, with numeric handle value n corresponding to g_unix_fd_list_peek_fds(...)[n].

  Being able to send and receive file descriptors that are not referenced by a handle (as in OpenFile here) is a quirk of the GDBus API, and while it's entirely possible in the wire protocol, other D-Bus implementations like libdbus and sd-bus typically don't provide APIs that make this possible.

  Reproduces: #2074 (closed)