Allow context.provider to accept a list of providers for provider-agnostic rules

[intelligent-ears]

Currently, rule types must specify a single context.provider value (e.g. github or gitlab). This means that rules which are completely provider-agnostic — using only git ingest and generic file checks — must be duplicated for each provider.

Example: The OSPS Baseline level-1 rules in minder-rules-and-profiles that use git ingest (e.g. osps-le-03-01, osps-gv-03-01) are identical except for context.provider. See mindersec/minder-rules-and-profiles#401 for a concrete example.

Proposed change: Allow context.provider to accept a list of provider types, e.g.:

context:
  provider: [github, gitlab]

or alternatively a special value like any for truly provider-agnostic rules.
This would eliminate duplication and make it easier to add support for new providers like Forgejo in the future.

[evankanderson]

It appears that context.provider is ignored (maybe we should warn if it is present?) as of #2843.

This introduces an opposite problem, where we may try to execute a ruletype that requires certain provider features against an entity which does not support them. Without thinking about it too deeply, it might make sense for a ruletype to optionally list a set of ProviderTypes that the entity needs to support for rule evaluation to succeed, and then filter evaluations based on supported interfaces.

[intelligent-ears]

That's really helpful context. So the duplication in mindersec/minder-rules-and-profiles#401 is actually unnecessary — the existing GitHub rules would already apply to GitLab repositories since context.provider is ignored. Should I close mindersec/minder-rules-and-profiles#401 and instead just rely on the existing GitHub rules for GitLab? Or is there still value in having explicit GitLab-labeled rules for clarity?

[evankanderson]

It might make more sense to either close 401 or to replace it with a removal of the context field across the baseline.

We should probably figure out some way to designate which baseline rules have GitHub dependencies, and how to implement GitLab equivalents (either in the same rule, or in a separate rule which runs conditionally).

That design probably falls under the roadmap for improved provider support -- when we mostly had one provider, it was easy to ignore these issues.