CHANGE: Use Protobuf for UDP messages

[Krzmbrzl]

Previously Mumble was using a custom binary format for transmitting data
via UDP (mainly audio). This has worked for a long time but besides
being inconvenient for 3rdParty implementors (they had to manually
re-implement encoding and decoding support for this format) this format
was not very flexible and changes to the data format were very hard.

In order to improve on this situation, this commit introduces changes
that allow to use Protobuf for the UDP messages as well (it's already
used for TCP). With that it should be relatively easy to extend/change
the UDP packet formats in the future and 3rdParty implementors can now
simply use Protobuf to handle decoding/encoding packets for them (much
less work and much less prone to errors).

Since the new Protobuf format is incompatible with the old UDP format,
this commit also includes support for dealing with older clients or
servers that don't recognize the new protocol yet. That way the new
protocol format is only used if both the client and the server are
recent enough to have it implemented (assumed to be the case >=1.5.0).

Note also that the server will make sure that clients using the old and
the new format can seamlessly communicate with one another.

Therefore, on the surface it should not be noticeable to the user which
protocol is currently used.

Note also that the new protocol format only supports Opus as an audio
codec. If one of the legacy codecs is to be used, the legacy packet
format has to be used as well. However, all codecs except for Opus will
be removed from Mumble in the future anyway.

Fixes #4350

NOTE: When this gets merged, all clients and servers claiming to support the protocol version 1.5.0 that do not include these changes, will become incompatible with the ones that do integrate these changes. This is important for everyone closely following our upstream master branch. A simple update to the latest code changes (including the changes from this PR) should be enough to restore full compatibility.
All servers and clients of version < 1.5.0 will be not affected by this as this PR is completely backwards compatible with those clients.

Checks

• My commits follow the commit guidelines

[Krzmbrzl]

I'll format and squash the commits after review.

---

@radioactiveman you are the maintainer of the AUR Mumble package that tracks Mumble master, right? If so the note in the above PR description is probably important for you (and your users) ☝️

[radioactiveman]

@radioactiveman you are the maintainer of the AUR Mumble package that tracks Mumble master, right? If so the note in the above PR description is probably important for you (and your users)

@Krzmbrzl: Yes, that's right. But if I understand it correctly, Mumble clients compiled from master are compatible with older versions (server and client). Only if the server is updated as well, this may cause compatibility issues with older clients. Is this correct?

Related to this PR: Please adopt the hint by @Polynomial-C in #5584 also here for the new gsl make-dependency.

[Krzmbrzl]

But if I understand it correctly, Mumble clients compiled from master are compatible with older versions (server and client). Only if the server is updated as well, this may cause compatibility issues with older clients. Is this correct?

Everything is compatible with each another, as long as everything that claims to run version 1.5.0 includes this PR. As soon as there is a communication of two instances claiming to run 1.5.0, where only one of them includes this PR (e.g. a server built from master before this PR was merged and a client built from master after the merge (or vice versa)), there will be an incompatibility and voice will not work. The reason for this is that the peer that has the changes from this PR included will use the new protocol (as it assumes that everything claiming to be >= 1.5.0 understands it), which won't be understood by the second peer in this scenario.

Related to this PR: Please adopt the hint by Polynomial-C in #5584 also here for the new gsl make-dependency.

Will do 👍

[Krzmbrzl]

@BombJovi see #5604 - you are not the only one seeing this error. In order to avoid it, you can use -Dwarnings-as-errors=OFF when invoking cmake.

Commenting here on GitHub is generally the preferred way to go, however it's usually more convenient if you commented on the respective pull request instead of directly on the commit itself as GItHub's UI in that regard just plain sucks (it's really, really hard to actually find these comments on larger commits)

[BombJovi]

Right on! Thank you for teaching me how how to proceed, Krzmbrzl! I'll for sure keep that in mind next time if I encounter any issues.