Fixes https://gitlab.freedesktop.org/zeenix/zbus/-/issues/124

azync::Connection rework

See merge request zeenix/zbus!225

We only need the `block_on` function so this makes sense.

Since both API are now very similar, this allows us to drop a lot of
duplication between the two. This also show that they really are almost
the same, just that one is sync and another async. This will make
creation of the high-level API very easy.

We can't just implement AsRawFd here as that's synchronous and we need
this to be async because we need to acquire an async lock.

Just like the sync Connection. This makes it possible to share it
between different tasks/threads.

Now that we use separate sockets for reading and writing, we can do this
w/o having to worry too much about all kinds of deadlocks. There is
still at least one kind of deadlock possible but that's also the case
with synchronous Connection and is well documented.

We'll use it in the following commit to switch azync::Connection to use
interior mutability.

We'll need this for switching to interior mutability in a following
commit.

At the moment, this only make azync::Connection more consistent with
Connection but doesn't give us any advantage but it will when we move to
interior mutability in a following commit. Then it'll help us avoid
deadlock when user reads and writes to the same connection at the same
time.

This commit turns the generics of azync::Connection into a private
detail. This means users don't have to worry about which transport type
is being used underneath.

This also implies that users can't just plug-in a transport in a
connection. We may provide a way to do that in the future using trait
objects (which is what we use internally now) or encourage people to add
transports directly into zbus itself.

We'll soon be making azync::Connection non-generic, where transport type
used will be an internal detail, just like for sync Connection. So let's
drop this hard to use type that won't be useful after that.

RFC: Untie Connection from UnixStream

See merge request zeenix/zbus!221

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

The async version uses the Async implementation.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

This will allow various Socket implementations to be used as Connection.

I don't see much need to make this generic over S: Socket, and it would
be a big API breakage. Another potential option is to have an enum for
known Socket types, but this will likely not have any performance impact
and just make the code more complicated and bloated.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

Make it generic over S, allow further refactoring.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

They are not really unix specific, even if they take UnixStream as
argument atm. We are going to change that.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

This prevents trait from being object-safe

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

This module doesn't have known users and was introduced without proper
tests or example. keeping stability guarantee there would be pointless.

Remove unused functions to clean the new warnings.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

This module doesn't have known users and was introduced without proper
tests or example. keeping stability guarantee there would be pointless.

Remove unused functions to clean the new warnings.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

We want to hide handshake & raw low-level details.
This API requires low-level details, without explicit test or example.

It's not clear to me if it would have any user.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

Some breaking fixes

Closes #63 and #110

See merge request zeenix/zbus!224

This includes

* The default handler in Connection, which became useless after we
  started queueing incoming messages.
* The TLS errors that are no emitted ever by our API.

Fixes https://gitlab.freedesktop.org/zeenix/zbus/-/issues/110

These were only kept around for backwards compatibility.

Fixes https://gitlab.freedesktop.org/zeenix/zbus/-/issues/63

Independent reading from and writing to a Connection

Closes #122

See merge request zeenix/zbus!223

By using separate socket handles we make reading completely independent
of writing. This fixes a deadlock when one thread tries to sending a
message on the connection while another is busy reading from it.

Fixes https://gitlab.freedesktop.org/zeenix/zbus/-/issues/122