[libgpiod] Thread safety API contract

["Erik Schilling" <erik.schilling@linaro.org>]

Hi all!

Currently it looks like libgpiod does not document any kind of thread
safety gurantee. However, the Python bindings tests
(test_request_reconfigure_release_events) are using sequences like this:

Thread 1 creates chip + some watches
Thread 1 creates Thread 2
Thread 2 issues a request_lines on the chip
Thread 2 reconfigures the line direction
Thread 1 joins Thread 2
Thread 1 closes the chip

Implicitly this depends on a couple guarantees:
1. Calling chip-related functions does not require synchronisation
   primitives (other than keeping the chip open).
   -> wait_info_event, read_info_event and request_lines are called
      concurrently
2. Requests may be modified by other threads
   -> at least reconfiguring the direction is done

Looking at the C implementations, it indeed looks? like this is a safe
thing to do - with the current implementation.

My question is: Is this an intentional gurantee that will be guranteed
in future releases? I am trying to figure out whether the current
contract exposed by the Rust bindings is correct and/or may need to
be extended. So which guarantees are provided by the current and future
C lib?

Currently, the Rust bindings are advertising that the chip may be `Send`
to other threads. This means one thread may forget about it and another
thread receives it. In contrast, a request for a line is currently not
allowed to be transferred to other threads (it is missing the `Send`
marker).

While in C and C++ thread-safety is typically not enforced by the
compiler, Rust has mechanisms to do this. But I would like to document
the C lib's situation before inventing rules for the Rust bindings :).

Trigger of my question was that we glossed over these details in
vhost-device-gpio:

https://github.com/rust-vmm/vhost-device/pull/435#issuecomment-1717205620

- Erik