Implement a way for individual repositories to control their QA requirements

[ferringb]

QA rules are repo specific; currently there is hardcoded awareness of the gentoo repo in pkgcheck to control certain checks, demonstrating "one size don't fit all".

See #769 ; in that case, the requestor will explicitly want that a defaulted 'on' check for their repo, something gentoo-x86 absolutely wouldn't want.

A bit like #763 , pkgcheck should be be told by the repo and involved code, what should and shouldn't be used.

These are the design constraints in my view:

1. The format is versioned. We'll presumably never get past v1, but gentoo history is one of "getting out of the corner we backed ourselves into is a PITA".
2. By default, pkgcheck builtin checks are enabled. The configuration is explicitly opt-out for pkgcheck bundled checks.
3. Repo's must be able to disable built in pkgcheck checks.
4. Repo's must be able to require checks- whether pkgcheck or provided by a third party addon (3rd party checks to be addressed later- the format must allow for this however).
5. The format must not prevent future addition allowing configuration directives for checks. Consider StableKeywordsCheck: detect packages using stable keywords #769 ; they require unstable globally. For my personal repos I will stabilize that which I can test- amd64- but would want every other arch marked as unstabled. IE, my repo would require a configuration directive.

The design for the configuration directives isn't in this scope; what's in the scope is that we must not prevent such a thing being added.

The location of this file is proposed as metadata/qa.conf, or akin.

Based on those requirements, my thought is this is best served by using TOML. I'm unaware of any tooling for providing a TOML 'spec', but that would be desirable here (and would be a builtin check, obviously).

@ulm , @thesamesam , @arthurzam : thoughts?

[ferringb]

For the configure a check, other requirements:

1. end users need to be able to see what configurables actually exist for the check. Effectivelly, they need to be able to pull a --help out of it.
2. realistically for everyone's fucking sanity, whatever reads the qa.conf needs to enforce type conversion and validation against the 'spec' of the configurable. The check shouldn't be responsible for forcing int conversion on something, for example, or trying to decide if the value is in {'yes', 'Yes', 'true', 'enabled', 'disabled', 'no', 'false'}, etc. The type 'language' has to be handled by one of our layers, forcing an explicit contract between that file, our parsing, and what checks can expect for the types they get passed.
3. Implicitly, this means there needs to be some base set of primitive types that are allowed for this configurable directive.

Offhand, I know y'all loathe pkgcore's config subsystem. It existed long before annotations and typing existed, but what it does, is exactly that, and what point 2 and 3 are about. After I refactor the config subsystem I expect it'll be able to address what we need here, in a way that isn't so god awfully opaque.

If it does, cool; if it doesn't, we just find another way.

Note that my intention of this allowing 3rd party checks to be integrated does bring the plugin discussion back into play. I'm aware of the feelings on that one, and I'll bring it back up to people after I do necessary refactoring in pkgcheck- which implicitly is going to open up a saner version of 3rd party support should we wish to do that.

All of this is not a requirement upfront; the first thing shipped should just be the ability to enforce or disable specific checks, or enforce an explicit "just these" checks. That's the end user requirements; our requirement is to allow the things I've raised that will be likely implemented in the future.