Enforce config accuracy for `workflow_settings` that don't apply to all combinations

Part of #2582 There are two main axes here: * linting/raising is config under `workflow_setting` requests something that we know the underlying platform/provider cannot actually achieve * distinguishing the various _actual_ providers that are currently hiding behind `provider: github_actions`. Some relevant quotes from #2584, where this was recently discussed (this may be my bias, feel free to edit if you have the rights, or comment what's missing). --- @h-vetinari > @mgorny: However, for now it's only doing anything on Windows GHA, and it's unclear to me if any other CI provider will ever feature reusable free space. Can we raise an error if it's specified too broadly (i.e. anything more general than `os: win` AND `provider: github_actions`)? This kind of thing has been one of my concerns since the introduction of `workflow_settings:`; I don't want people to wrongly believe something is more general than it actually is. That's both a bad developer experience (to find out after bashing your head against the wall why things don't work as expected that the option doesn't actually do what you thought it would), but more importantly, it precludes us from ever expanding such options to new or existing providers in a way without having to potentially deal with the aftermath on affected feedstocks. --- @h-vetinari > @mgorny Sorry, what I meant is that even most GHA providers won't do a thing here This actually highlights a bigger problem. Currently we have various different CI providers that are all lumped together as ```yaml provider: <target>: github_actions # is it MSFT, namespace, blacksmith, depot, cirun?! ``` so we cannot reflect this (IMO necessary) distinction in our `workflow_settings` yet. Do we want to add a (ignore bikeshed colour) `subprovider:`? Or should we break up `provider: github_actions` into smaller pieces? --- @jaimergp > @h-vetinari: Or should we break up provider: github_actions into smaller pieces? That's going to create some churn. What if we introduce a syntax to glob/match github_actions_labels? This way we don't have to keep definitions so up-to-date. Like: ```yaml provider: <target>: github_actions@/glob-or-regex-goes-here/ ``` --- @h-vetinari I like the `github_actions@<actual_provider>` idea. It's nicely concise and self-explanatory. I don't think we'd even need to glob or regex necessarily, just bare values `github_actions@namespace` would be enough for the vast majority of cases I could imagine that need the provider-distinction (not least because you can always add another `workflow_settings: foo: ...` list entry if there's more than one provider in play). Naturally, `github_actions` without the `@` would mean all possible providers, and we could hint (rather than lint) if certain requested features are not available on the provider that's requested through `github_action_labels`. --- @h-vetinari > @mgorny: I'm sorry but I don't really see what that'd accomplish. As a concrete example for `resize_partitions`, which only really works on `cirun` (AFAIU) <details> ```yaml workflow_settings: resize_partitions: - value: true provider: github_actions # --> lint, not restricted to win workflow_settings: resize_partitions: - value: true provider: github_actions os: win # --> hint if github_action_labels specifies a non-cirun provider for windows workflow_settings: resize_partitions: - value: true provider: github_actions@cirun os: win # --> no hint or lint, because the config is restricted to a combination that's known to work ``` </details> --- @mgorny That said, such level of granularity doesn't seem helpful. In the end, I don't expect people to be using two different GHA Windows providers simultaneously. What we've done with PyTorch feedstock was not only rare, but awfully hard to set up in the first place.