Support for Scalelite Tagged Servers

[Ithanil]

This PR adds frontend support for "Tagged Servers" in Scalelite, a feature which is described here: blindsidenetworks/scalelite#1049

Description

This PR allows user to configure two new options for each room:

1. The server tags from a pre-defined list
2. Whether the the server tag is hard required or fallback is allowed when no server is available

In terms of UI, it presents itself as seen in the following screenshots:

The list of available options is defined by the Greenlight administrator and certain tags can be restricted to certain role ids. In the current iteration of this feature, this is done via .env config file and is documented in sample.env:

## Support for Tagged Servers
# If your Greenlight instance is connected to Scalelite or another Loadbalancer with enabled support for the 'meta_server-tag'
# parameter on create calls, you can use the following variables to configure support for this feature via the Greenlight UI.
# Example (delimiters are , : and /):
# DEFAULT_TAG_NAME=Standard # friendly name for the untagged/default servers
# SERVER_TAG_NAMES=tag1:Name 1,tag2:Name2  # defines available tags and their friendly names
# SERVER_TAG_ROLES=tag2:xyz-123-321-aaaa-zyx/abc-321-123-zzzz-cba  # allow tag only for given role ids (see role ids in DB)

The required database migration is included and well tested. No RSpec tests have been added, but the feature is tested in deployment for multiple rooms, configuration combinations etc.

Notes

• Currently, if a room has been configured with a tag and then later the tag is removed from the site-wide configuration or permission is revoked for the user's role, the room's configured tag will remain in the database and will still be used for create calls. However, the configuration field will show as empty in the UI and only allow changes to valid/allowed tags. Solved by commit 29c0c49
• Currently, the role-based restriction of tags is only done by sending a list of allowed tags to the JavaScript code and not again validated on the backend side. This seems OK as long as the impact of potential malicious users abusing known "VIP" tags is tolerable.
• The two server tag options have already been added as global room configuration options (for consistency and for not requiring any future migrations), but are neither available for configuration in the admin UI nor does their value override the individual room's configuration.

What is "missing" / Future Development

• Add a sync task for the administrator to remove invalid tags from rooms after configuration file change Done (29c0c49)
• Validate role-based tag restriction on backend side (I could use a hint on how and at which point this should be done ideally, would also be happy if someone else could contribute this)
• Make the global server tag options configurable, via the global room setting UI, and make their values actually work as overrides. (I'm not going to contribute this)
• Translate the current file/env-based configuration to UI-based configuration in the site and role setting menus. (I'm not going to contribute this)

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud