Harden Jamulus server for unwanted connections

Even though #2935 is already old, I think we should still consider hardening the "connection" process.
@dtinth proposed a "waiting room" approach, which we kind of already have (we already have something like this: https://github.com/jamulussoftware/jamulus/blob/2505a3154aa69459d5bcb3ae0ff8d189fdb0cb83/src/channel.cpp#L39).

> I have another suggestion for a fix.

> Problems with checking for valid audio packet is that we need to know 2 things in order to successfully decode a packet: (1) which decoder to use and (2) whether sequence numbers are used. These information is sent out-of-band and not in Opus audio packet, so we need to know their `NETW_TRANSPORT_PROPS` before we can succesfully decode an audio packet. We can also brute-force all combinations but efficiency is in question.

> So here’s a new proposal:

> Upon server receiving a packet from an unknown source, put them in a **waiting room** (do not assign a channel ID yet, dropping all audio packets in the meantime) and send it `PROTMESSID_REQ_NETW_TRANSPORT_PROPS`. It turns out that a Jamulus client can respond to that message before it has a channel ID assigned. Once an acknowledgement (or a reply, or a well-formed reply) is received, move them from waiting room to **jamming room** (where all messages are processed as usual).

_Originally posted by @dtinth in https://github.com/jamulussoftware/jamulus/discussions/2935#discussioncomment-4191832_

Start with the linked logic in src/channel.cpp, then trace how unknown sources receive channel IDs and how PROTMESSID_REQ_NETW_TRANSPORT_PROPS is handled. Determine the existing connection state flow before evaluating the proposed waiting-room behavior. Done means unwanted sources are not assigned a channel or allowed to process audio until their transport properties are acknowledged.

Written by the indexing model from the issue text.