refactor(disruption): use fixed maxUnavailable

[hspedro]

Some schedulers might decide on a high readyTarget, which means a low amount of occupied rooms in regards to total rooms, this causes the PDB to have a relatively low number compared to the total. Since PDB does not filter by room status, we are still subject to many rooms being evicted and the system is highly impacted. To mitigate this, Maestro will now set a fixed amount for maxUnavailable with the default value of 5%. It can be configured via:

MAESTRO_SERVICES_SCHEDULERMANAGER_DEFAULTPDBMAXUNAVAILABLE="10%"

The variable accepts integers greater than 0 and percentage strings.

Summary of changes

• Added a new variable on Scheduler proto for pdbMaxUnavailable that is a string
• Added this variable to the payloads of creating and updating a scheduler
• Added validation for this field checking for integers below 1 and percentage values below 0 and above 100
• Added a config to SchedulerManager with the DefaultPdbMaxUnavailable. This config is in the YAML as well with the default value of 5%
• Refactored RuntimeWatcher to remove the MitigateDisruption call based on the number of occupied rooms
• Refactored runtime Scheduler with Create, Delete, and UpdateScheduler functions that update the namespace PDBs
• Added a check to Scheduler's NewVersion operation to check if pdb max unavailable changed and call the runtime update to reflect the PDB change

Scheduler Usage

pdbMaxUnavailable: "15%" # or 50 (any integer >1)

[reinaldooli]

I believe it's better to make this configuration scheduler/game basis. We might end up with different games in the same cluster asking for different configuration values.

[joaobologna]

LGTM