Change VoipClient to be informed of the message being radio or local by VoipServer instead of by re-running the checks ran server-side..

[BramvanZijp]

Change VoipClient to be informed of the message being radio or local by VoipServer instead of by re-running the checks ran server-side.

Reasoning why is explained in #16969 (Moved to #16978).

Unlike #16970, which simply removes the check, this PR takes advantage of the fact that that exact check is already ran server-side, and simply includes the result of that check in the packet sent to the client as a boolean value.

NOTE: This WILL require testing with another person (which I am unable to alone), though I see no reason why it would not function.

[BramvanZijp]

Resolves #16978

[Regalis11]

I think the approach looks mostly good, however I found some parts of the code confusing. It's now quite unclear what the isRadio variables mean in the server-side code.

[BramvanZijp]

Had to add one of the CanUseRadio checks back to VoipClient because that outputs the senderRadio variable, which the client does need for the radio messages.

Furthermore, clarifying comments were added to more clearly explain isRadio's purpose.
I have not had a chance to test the changes with anyone yet, but if I find somebody willing to help, I will.

[BramvanZijp]

Had to add one of the CanUseRadio checks back to VoipClient because that outputs the senderRadio variable, which the client does need for the radio messages.

Furthermore, clarifying comments were added to more clearly explain isRadio's purpose. I have not had a chance to test the changes with anyone yet, but if I find somebody willing to help, I will.

If we want to instead include senderRadio.range as another part of the packet and then keep CanUseRadio serverside only, we COULD, though I am not 100% sure if thats really worth it. (As somebody not knowledgable on the networking part, I am not sure how much bigger we really want to make each message to each client, because IIRC they are sent VERY rapidly. If adding an extra number is a non-issue, however, that WOULD be the ideal solution, but I worry it may cause issues as that would put a hard cap on the max range radios can be given due to the byte size.)

[Regalis11]

The comments clarified this a bit, but one of the newer changes seems strange and potentially incorrect to me.

[BramvanZijp]

Updated the code to simply fetch the radio client-side, and assume the default range value of a headset if that fails (Which it will not unless mods directly impact the outcome of CanUseRadio).