Swarming: Creates Feature Flag to control its usage

[IvanBM18]

Continuing the swarming efforts, we add a new Feature Flag to control wether swarming tasks are allowed or not to be scheduled. so for this:

• Add a new filter in the is_swarming_task to check for the feature flag
• Implemented a UT to verify that when a feature flag is not found in the DB we return false or empty values

---

dev environment test proof

This feature flag has been present in the dev env DB since last monday, but this changes were present in dev under the previous swarming state (see this PR), still the metrics seemed healthy from monday to wednesday , worth nothing that it has been set on false:

So today i send them back again to dev to test this changes after the rollback and metrics continue to be healthy and no regressions seem to be introduced cause of this error. The only noticable error i saw in the logs is:

Which seems unrelated.

[letitz]

If it were me, I would put this flag in the yaml config at the root instead of in the database. Seems to me that even if we want to Turn It Off Now, we could do a rollout with a new config file / rollback to the previous version, instead of flipping a bit in the database (which leaves no audit trail, requires no review, and makes an instant global config change).

I defer to ClusterFuzz maintainers however on their method of choice for gating new functionality.