R&D NORM Groupchat

[DJ2LS]

This PR is for R&D for working on a NORM ( NACK Oriented Reliable Multicast https://en.wikipedia.org/wiki/NACK-Oriented_Reliable_Multicast ) Groupchat and for getting a feeling about the needs for database structure and the protocol itself.

⚠️ Developer Notice
This Pull Request is under active development.
Please do not use or merge unless you are directly contributing to this feature.
⚠️

Goal is, working constantly on this one, while we keep up2date with latest code in develop branch. This PR is considered to be a midterm work package.

Because of the limited nature of RF transmissions, we can't implement NORM 1:1, but we can let us inspire.

How it should work:

• Station A sends data "Hello World....^snip^". This data will be split into bursts of fixed sizes. In this case we talk about 3 bursts, but up to 15 are possible

• Every burst contains the full message header

• Station X receives burst 1 and 3

• Station Y receives burst 1 and 2

• Station X and Y requesting retransmission of burst 2 ( X ) and 3 ( Y ) via broadcast request

• Station A receives the request of Station X and sends burst 2

• Station X receives the request of station Y and sends burst 3

• Station X and Y both receiving the corresponding data and all data can be assembled internally - success

• Meanwhile Station Z also heard the burst retransmissions and continues with the same requesting procedure ....

Todos:

• Basic frame structure for NORM 🚧
• Database parts 🚧
• API Endpoints 🚧
• Full test covered 🚧
• GUI🚧
• NORM: Request missing data🚧
• NORM: Transmit requested data🚧
• NORM: Define a burst lifetime, until we resend data🚧
• NORM: Define message types which make sense for broadcasts, have a log at EMCOM needs as well🚧
• FIX: Correct message type by flag - we have to get a string from flag-int
• NORM: Handle priority correctly with schedule managers
• API: transmissions are blocking, we have to make them asynchronous

[DJ2LS]

Basic message handling via GUI is now possible. This should make development easier.

[DJ2LS]

Stuff to think about:

How do we handle start of repeating messages?

• Should we do this cyclic via schedule manager, maybe checking for assembling status in database combined with last received timestamp?
• Should we trigger this after a specific time, bursts have been received? Maybe calculating some time after a burst has been received, and the time left until total bursts have been processed, then sending a repair burst?
• What's the time to life for a broadcast until we don't answer repair requests anymore?

[DJ2LS]

Options:
Enable / Disable broadcasts
Send repair requests
Broadcast Lifetime
Respond and listen only to specific broadcast domains