Add WithRelatedCheckConfigs option to check additional check configs for unused plugins warning

[doriable]

We check for unused plugins when running Lint,
Breaking, and ConfiguredRules. However, this is based
on the provided CheckConfig, and does not account for
configurations outside of the current check. This results in a
confusing unused plugin warning for users who may not have
configured rules and/or categories configured for all modules
in their workspace.

This PR introduces a WithRelatedCheckConfigs, that allows
us to provide additional check configs to check plugins against.
It also allows us to no longer rely on the heuristic to ignore plugins
with multiple rule types -- we can provide all related check configs
and check against those.

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Dec 19, 2024, 7:53 PM

[emcfarlane]

The case above (In client.Lint and client.Breaking, we only have the Lint or Breaking config) could probably be removed now to say related configs are provided for validation and remove the heuristic workaround based on other rule types.

[doriable]

So this is one I was kinda hoping to get opinions on. Currently, I am only providing the respective other check configs (e.g. other lint configs for lint, other breaking configs for breaking), but yes, we could provide both instead, and that would allow us to remove this clause and rely solely on the related check configs. I like that idea, but I wanted to get others' opinions on this.

[doriable]

I thought a little bit more about this, and the goal of this is to provide users with a clear warning for whenever a plugin does not have any configured rules and/or categories. And so I think it actually doesn't make sense to rely on the heuristic, it seems we are doing this because RulesConfig always only ever applies to a single RuleType:

buf/private/bufpkg/bufcheck/rules_config.go

Line 126 in b4d7836

ruleType check.RuleType,

However, at the time of the validation, we have access to all rules, and so we can check all related check configs, agnostic to rule type, which would allow us to surface a much clearer warning to users without relying on a heuristic.

So I've pushed up an update which removes that heuristic and instead sends all related check configs and checks them for the warning.

[bufdev]

It looks like if you specify the WithRelatedCheckConfigs option, these CheckConfigs are not additionally checked, rather these CheckConfigs are the only CheckConfigs that are checked, and the original CheckConfigs (?) from allRules are not checked. Am I wrong/does this make sense? Make sure it is additional.

[doriable]

Yep! On lines 294-305, we are still checking the original configurations, we are just checking the additional rules in lieu of checking whether the plugin has rules from other rules types.