Add command to initiate a vote for boss-restricted $-commands.

[DeviousNull]

Note: This PR should be considered a proof-of-concept/work-in-progress, and is submitted to request feedback/review. This is the first non-trivial Teiserver change that I've written, and I am not experienced with Elixir; so I'm not confident that I'm following the idiomatic patterns for the language.

Currently, a boss is often democratically elected in order to make a relatively-minor settings change, rather than for lobby management reasons. However, this is not-uncommonly subject to abuse; a player may lie (or just not tell the whole truth) to be voted as boss, and then they may take actions other than what the rest of the lobby expects.

This PR seeks to provide an alternative way for a democratic lobby to change certain settings, without electing a boss. It does so by making the following changes:

• Add "$cv <...>" command to allow voting on whether to run a whitelisted $-command, without using boss privileges.
• Add "$ev" command to cancel a running vote.
• Extend "$y" and "$n" (currently used for "$splitlobby") to also update votes for "$cv".

The general flow of these commands is as follows:

1. A player runs a $cv command to change a setting. For example: $cv minratinglevel 1
2. Over the next 30 seconds, players may say "$y" or "$n" to place their votes
3. After 30 seconds, if the number of $y votes is higher than the number of $n votes, then the command executes as if the Coordinator had run it.

Some restrictions have been created for the above commands:

• $cv can only be used with commands that have been whitelisted for voting.
• $cv cannot be run by spectators
• $cv cannot be run by players when a boss is present
• $ev can only be run by the player who ran $cv (or privileged users)

The following commands are currently whitelisted for voting:

• welcome-message
• rename
• minratinglevel
• maxratinglevel
• setratinglevels
• resetratinglevels
• minchevlevel
• maxchevlevel
• resetchevlevels

The patch was tested in my local dev environment, but I plan to do additional polishing/testing. I am submitting this PR now for early feedback, particularly regarding any preferred ways to implement this feature, so that less work is wasted if a change in approach is needed.

[DeviousNull]

Example screenshot of what the voting process looks like:

[DeviousNull]

Currently planned additions:

• Either detect when a game is running, or require a minimum % participation.
• Add a cooldown to how often votes can be called (50% of duration?)
• Immediately end the vote if there are enough voters to make a decision
• Write unit tests

[jauggy]

If you want to make these commands voteable similar to the other SPADS commands, have a look at Yaribz response to my question: https://discord.com/channels/549281623154229250/564591092360675328/1261943858514624605
He linked some tutorials. Might be useful. But it would require writing some python.

[DeviousNull]

That's an excellent reference, thank you. I'll look into a SPADS-plugin-based implementation; I expect it will provide a more user-friendly system.

[L-e-x-o-n]

As @jauggy said, doing it like SPADS commands allows better UI. I think @Beherith is already working on it and got some commands done.

[DeviousNull]

I've just created a PR for a SPADS-based implementation, and yes it is much prettier than this PR was: beyond-all-reason/spads_config_bar#134

I'll go ahead and close this one now. Thanks, all!