This adds a Gateway Mesh section to the web-interface (+ API endpoints)
to see the status op each Relay Gateway within the Gateway Mesh.
The Gateway Mesh (https://github.com/chirpstack/chirpstack-gateway-mesh)
is an experimental feature to extend LoRaWAN coverage throug Relay
Gateways.
All these files can be generated using the `make api` command and there
is no real need to commit these into the repo. Only the api/go files
need to be comitted of how the Go import system works.
This also updates the Rust, Go, JS and gRPC-web (JS) code generation and
UI build to use the nix-shell environment instead of using Docker.
This implements end-to-end encryption between the end-device and
end-application. The encrypted AppSKey or SessionKeyID is forwarded to
the end-application which should be able to decrypt or request the
AppSKey to decrypt the uplink payload. As well the end-application will
be able to enqueue encrypted application payloads.
Using this mechanism, ChirpStack will never have access to the uplink
and downlink application-payloads.
This makes it possible to add gateways to a multicast-group, which in
case configured will always be used for transmitting the multicast
downlinks.
This also moves the multicast class-c scheduling to the multicast-group
configuration. Options are delay between multiple gateways, or GPS time
synchronized transmission.
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.
