In some scenarios, this check returned true while the avx2 extension was
not available (e.g. QEMU emulated CPU).
See for more details: https://github.com/RustCrypto/hashes/pull/386.
This changes the clean_session default to false, as only in case of a
persistent session, qos > 0 would be effective. If the client_id is not
set, then ChirpStack will generate a random client_id, which stays the
same during the lifetime of the chirpstack process.
This also implements a subscribe loop, as the client re-connect feature
does not re-subscribe. Even in case of a persistent session there is no
guarantee that the subscription is recovered, as it might have been a
MQTT broker restart. In case the broker stores the sessions in-memory,
the client would re-connect, but without subscriptions.
The (re)subscribe logic is placed outside the on-connected callback, as
the callback function must not block, thus can not wait for the
subscribe result. No the (re)subscribe happens async from the
on-connected.
Diesel 1.4.x makes it impossible to properly cross-compile when using
PostgreSQL and thus having a dependency on libpq. On compile and I
believe when using the diesel_migrations crate, there is a dependency on
both the host and target libpq. Unfortunately, only one can be installed
at a time, because of conflicts. See also:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995768
Until now the cross-compile solution is based on docker buildx, which
uses qemu to emulate the different targets. This works, but is very,
very slow.
Diesel 2.0.0-rc.0 no longer depends on both the host and target libpq on
compile and makes it possible to implement proper cross-compiling (using
the rust --target flag in combination with the cross-compile
toolchains).
This includes:
* Changing the modulation parameters to its own type.
* Changing the timing parameters to its own type.
* Change the gateway_id to string. As the json encoding for bytes fields
is base64, this was confusing some users.
* Change the uplink / downlink id to uint32 from uuid. A string
representation of the UUID field (for the same reason as the gateway
id) would consome quite some additional bytes. An uint32 provides
sufficient uniqueness for the purpose of uplink / downlink.
