Move approval criteria to CODEOWNERS

[joao-paulo-parity]

At the moment there's sometimes mismatches between the bot's internal rules and Github repository settings. The overarching idea for this effort is to move as much logic as possible to Github's CODEOWNERS, so that

• Rules are consistent between bot merge and Github repositories' own merge criteria
• Internal conditions are simplified: we'll mostly care about statuses being green without many extra rules on top of that

Our approval criteria's internal code will be removed in favor of having the same logic through Github CODEOWNERS. Those rules should have a fallback of core-devs & substrateteamleads so that functionality is maintained after the changes. Not having this fallback would result in all members of paritytech having the same approval weight as a core developer due to the organization's base write-access role.

Once CODEOWNERS is proper, relevant approval counts should take into account all members with write-access to the repository since that's what counts for Github's "Required approving reviews"; at the moment we only count core-devs & substrateteamleads so it's confusing when the quota is met on the Github but doesn't work for the bot. This count can be used exclusively for "pitching in the missing approval" since the mergeability will be checked on Github's side (PR will be {"mergeable": false} in the API the approvals aren't met).

---

See https://github.com/paritytech/ci_cd/issues/159#issuecomment-898223122 for motivation and context.

[joao-paulo-parity]

During preliminary testing on another repository I've found some CODEOWNERS rules not working as I'd expect. Contacted Github support about it and will follow-up here once it's cleared.

[joao-paulo-parity]

During preliminary testing on another repository I've found some CODEOWNERS rules not working as I'd expect

This was about teams not being assigned to pull requests even though they are part of the organization. As it turns out, those teams have to particularly be granted Write access through Settings -> Manage access like the following:

Otherwise, it will not work. i.e. it does not matter that the organization's base role already grants Write, the team has to be added manually all the same. ¯\_(ツ)_/¯

If we wanted to apply those rules to e.g. Substrate, for the fallback rule to take effect we'd have to add core-devs and substrateteamleads (or just the former if it already includes everyone from the latter) through Settings -> Manage access as explained above; of course, it would be the same way for any other teams which should be assigned to a specific file.

[joao-paulo-parity]

This feature will be superseded by https://github.com/paritytech/pr-custom-review

[joao-paulo-parity]

closed by #371