Round robin checks don't function properly with multiple subscriptions

[echlebek]

Expected Behavior

Specifying multiple subscriptions in round robin checks causes a union of all the agents with those subscriptions to become the ring that the check will execute in.

Current Behavior

Unique rings for each subscription are created and used.

Possible Solution

Either support unions of subscriptions (very hard or impossible under current design), or don't let people set multiple subscriptions on round robin checks. Additionally, don't let users set entity subscriptions on round robin checks.

[portertech]

TODO:

1. Document the current round-robin scheduler behaviour when more than one subscription is used
2. Log a strong message (warn level) when more than one subscription is used for a round-robin check
3. Incorporate this into the next iteration of check configuration/schedulring (i.e. Jerbs)

[calebhailey]

"JERBS"

[calebhailey]

Note to self: call out in the release notes that the "fix" for now is documentation + logging, but a future version may introduce new config validation rules...

[echlebek]

I think we should definitely make it a validation error in the next API version. Perhaps it's time to start tracking these "little things"?