Otherwise, we end up with a circular dependency between the
`ConnectionInner` and the `ObjectServer` task and hence dropping the last
`Connection` instance doesn't disconnect the underlying connection.

Fixes #308.

This is currently broken:

#308

This should have been removed in f2f86d5f.

If the broadcast channel already exists for a match rule-based message
stream and capacity is specified and is greater than current capacity,
then the capacity of the message queue is reset to the specified one.

Otherwise, the streams may not be created in time for the pipe to work
and messages could be lost.

Use events to sync server and client.

This is specifically needed by bus implementations where even the first
`Hello` method could be served through ObjectServer so we've to ensure
that ObjectServer is all setup before socket reader task starts.

Also rename the struct to SocketReader.

This means that pending method call future is only awoken for relevant
messages. Moreover, method calls are now independent of all other
message streams and hence there is a much lower chance of a deadlock
when a method call is pending.

As somehow it triggers a stack overflow there:

https://gitlab.freedesktop.org/zeenix/zbus/-/jobs/34023494

This means that ObjectServer task is only awoken for method calls.

This way, you can tell zbus to only wake-up the stream for the message
it's intersted in. We leverage the existing internal API for match rule
registration/setup, which will help us convert SignalStream (and other
MessageStream users) to make use of this new API.

Fixes #233.

This simplifies the MessageStream impl a bit but mainly we need this for
a following change on how message broadcast works.

Until now, we have been using the default behaviour of async-broadcast
to await for active receivers (which translates to existance of any
message streams) when sending a message received on the socket. This has
been the right thing to do since otherwise, we'll needlessly keep
reading messages on the socket.

However, we are about to introduce multile broadcast channels in the
following commits and it wouldn't make sense to make active receivers of
one channel wait for active receivers on others.

Latest clippy gained a warning lint about this:

```
error: variables can be used directly in the `format!` string
   --> zbus_macros/src/proxy.rs:199:30
    |
199 |             .or_else(|| Some(format!("/org/freedesktop/{}", ident)));
    |                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
help: change this to
    |
199 -             .or_else(|| Some(format!("/org/freedesktop/{}", ident)));
199 +             .or_else(|| Some(format!("/org/freedesktop/{ident}")));
    |
```

Luckily, clippy can fix it automatically for us as well.

I guess at some point the internal MessageReceiverTask needed Arc
wrapping but seems not needed anymore.

Now that our error type implements `Clone`, we can broadcast the whole
Result<Arc<Message>, Error> on the broadcast channel to the message
streams.

This is so that we can implement `Clone` for `Error` in a following
commit w/o ending up tranforming all I/O errors to generic string
errors during cloning (`std::io::Error` doesn't implement `Clone`[1]).

We still keep `Io` variant around for backwards-compat but we deprecate
it and don't return errors with that variant for any of our API anymore.

[1]: https://github.com/rust-lang/rust/issues/24135

This fixes a regression from 17a04a49.

Just like other call_method calls, this shouldn't require caller to
assemble the message but rather be generic.

Conditionally use the experimental API to give names to tasks so
tokio-console can show our tasks by name and users/us will have a much
better luck reading the console output.

`tokio_unstable` cargo flag will need to be specified though but we
leave that to the users.

The method name should be part of the task name.

This should have been part of fd602728 but only get caught after
a2a2ab14 and 295bde06.

Mostly about unused variables and imports.

Let's provide API in `Connection` and advertise this over the raw fdo
one so that even in case where `Connection::request_name` is
insufficient, user can register names through `Connection` and we can
track them.

Fixes #291.

We were only doing this for p2p case but we should do this for bus case
well. Otherwise it breaks things for folks who were using
fdo::DBusProxy::request_name along with ObjectServer for any reason.

Fixes #289.

Add `{add_match,remove_match}` replacements that make the same
underlying D-Bus calls but make use of the new `MatchRule` type. We also
deprecate the `{add_match,remove_match}` to discourage use of these less
type-safe versions.

Use the new types instead of strings.

This is meant for bus implementations.

In such case, just register the name locally and not w/ the bus. This
allows users to tell the ObjectServer to only serve method calls
destined for the names it has registered. This is useful for bus
implementations.

While in most cases, you'd want ObjectServer to take over all incoming
method calls on its connection but in certain cases, you don't. For
example, if you'd build a bus implementation on top of zbus, you'll
likely want to make use of ObjectServer for the Freedesktop standard
interfaces required from a bus, while being able to receive messages on
the same connections destined for other peers to send them off to the
right connection. If ObjectServer would serve all messages, it'll just
return an error for all method calls destined for other peers.

I'm sure there are other (not so niche) use cases for this.