FEAT(client): Introduced new mumble API

[mryamac]

This patch introduces a new API to link, unlink, start to listen, stop the listen the channels and send the messages to the plugins

Checks

• My commits follow the commit guidelines

[Krzmbrzl]

Sorry for haven taken so long to review this. The proposed changes look mostly fine to me. The review comments are mostly about some minor coding style detail, some rewording of documentation or some small generalization of the proposed API.

[Krzmbrzl]

@mryamac could you please rebase your branch against current master? It seems like FreeBSD has bricked the Qt package again. However, we have recently switched to Qt 6 anyway so maybe that is enough to resolve the issue.

[Krzmbrzl]

I just noticed two more things

1. Linking channels and creating listeners in channels is subject to ACL restrictions. If the local user is lacking the respective permissions, the actions will (silently) fail. That's just what it is but one scenario that is not covered by this is the case in which the server admin explicitly grants certain permissions to the plugin that the user doesn't have. This is already possible for e.g. the requestUserMove function which accepts a password which can offer special ACLs for this specific call from the plugin. I think that the link- and listen-related API function should also allow for a password to be provided for such a purpose.
2. This PR introduces a function to send a text message to a group of users. I would propose to extend the function signature to also allow sending text messages to a given set of channels. Then the function can be used to either send to users or to channels or both at the same time allowing for maximum flexibility. Sending text messages to channels introduces ACL restrictions though so the same password parameter as proposed for the other functions would apply.

[Krzmbrzl]

Suggested change

	* @param message The message to send (UTF-8 encoded)
	* @param messageSize The size (in bytes) of the message
	* @returns The error code. If everything went well, STATUS_OK will be returned.
	*/
	mumble_error_t(MUMBLE_PLUGIN_CALLING_CONVENTION *requestSendUserTextMessage)(
	mumble_plugin_id_t callerID, mumble_connection_t connection, mumble_userid_t *users, std::size_t userAmount,
	const char *message, std::size_t messageSize);
	* @param message The message to send (UTF-8 encoded as a C-string)
	* @returns The error code. If everything went well, STATUS_OK will be returned.
	*/
	mumble_error_t(MUMBLE_PLUGIN_CALLING_CONVENTION *requestSendUserTextMessage)(
	mumble_plugin_id_t callerID, mumble_connection_t connection, mumble_userid_t *users, std::size_t userAmount,
	const char *message);

Sorry for reverting my own suggestion here. I noticed that we are using C-strings in other parts of the API already which inhibits null bytes from being part of it but since we use that for passwords, we can certainly use this for text messages which indeed can't contain null bytes.

[Krzmbrzl]

please #undef all macros at the end of the file

[Krzmbrzl]

All new implementations have to also check that the connection is synchronized.

[Krzmbrzl]

semantically it would make sense to keep the macros related to the connection together and then define this new macro either before both of them or after (but not in between)

[mryamac]

I just noticed two more things

1. Linking channels and creating listeners in channels is subject to ACL restrictions. If the local user is lacking the respective permissions, the actions will (silently) fail. That's just what it is but one scenario that is not covered by this is the case in which the server admin explicitly grants certain permissions to the plugin that the user doesn't have. This is already possible for e.g. the requestUserMove function which accepts a password which can offer special ACLs for this specific call from the plugin. I think that the link- and listen-related API function should also allow for a password to be provided for such a purpose.
2. This PR introduces a function to send a text message to a group of users. I would propose to extend the function signature to also allow sending text messages to a given set of channels. Then the function can be used to either send to users or to channels or both at the same time allowing for maximum flexibility. Sending text messages to channels introduces ACL restrictions though so the same password parameter as proposed for the other functions would apply.

For the first item, requestUserMove function uses
joinChannel(unsigned int uiSession, unsigned int channel, const QStringList &temporaryAccessTokens)

This function takes tempAccessToken, but in my cases, link/unlink vs. functions don't have any parameters like that. So, to be able to give permission, do I need to modify the ServerHandler class?

Item two seems clear to me. I will implement this API, but first, I need to understand the ACL case.