Serde DBUS

This crate is very freshly written and it is very much so "in development" and a work in progress. It does not yet support all the features of dbus. Please test thoroughly before using, and please feel free to contribute bug reports or MRs.

The goal of this crate is to provide serde support for the DBus message format. Actually sending the messages is outside of the scope of this crate. This crate can be used with a more complete messaging system like zbus, as an alternative to its bundled zvariant serde-implementation. It is, to be clear, a fresh re-implementation of serde for the DBus format, and not a fork of zvariant.

The primary difference between this crate and zvariant is that this crate intends to support serializing Rust structures as either DBus structures (e.g. with a signature like (iis)) or DBus dictionaries (with a signature of a{sv}) as equal first-class options. zvariant uses special structs with special known names to accomplish this, but serde_dbus instead can be configured with either an overall default (such as all structs with named fields become dicts whereas all tuple structs become structs), or a case-by-case basis with configurable lists of struct names.

This means that the same Serialize instance can be used to create DBus dicts as JSON dicts, which is an issue with zvariant that this crate exists to solve.

As a side effect of the reimplementation, instead of passing the signature of the entire structure as out-of-band data, as in zvariant, this crate requires use of SerializerPolicy to provide necessary out-of-band data. Due to constraints coming from serde, especially this bug which serde won't fix, use of SerializerPolicy will be necessary to provide item signatures for arrays (otherwise they will default to use variants and be av).

As of right now, this hasn't been implemented, and so arrays are currently only supported for the av signature. This is a known issue, and will be addressed in future versions.

The deserializer does not require any out of band information in any circumstance.

Performance has so far not been a substantial consideration, instead getting a working version out first, and then subsequently addressing performance.

Serializing will only be supported in little endian, but deserializing will have to support either endianness.