🌱 Add probes for Branch Protection

[AdamKorcz]

What kind of change does this PR introduce?

Feature

• PR title follows the guidelines defined in our pull request documentation

What is the new behavior (if this is a feature change)?**

This adds 9 probes for the Branch Protection check.

• Tests for the changes have been added (for bug fixes/features)

Which issue(s) this PR fixes

None

Special notes for your reviewer

The probes are not invoked anywhere by Scorecard; the PR does not change the evaluation. I will do that in a follow-up PR once this has landed.

Does this PR introduce a user-facing change?

NONE

[codecov]

Codecov Report

Merging #3691 (24f9b94) into main (c1a0557) will increase coverage by 2.23%.
The diff coverage is 74.12%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3691      +/-   ##
==========================================
+ Coverage   66.68%   68.91%   +2.23%     
==========================================
  Files         217      227      +10     
  Lines       15061    15347     +286     
==========================================
+ Hits        10043    10577     +534     
+ Misses       4434     4124     -310     
- Partials      584      646      +62     

[github-actions]

This pull request is stale because it has been open for 10 days with no activity

[spencerschrock]

Most of the reviewing time was spent reading the yaml definitions. I think some of these branch protection settings are easier to do than others, so I tried to leave comments on the ones I think are low/medium effort.

There were comments that applied to most of these probes, so I got tired of leaving them. They generally were:

1. mentioning the branch protection rules in general are only for default/release branches.
2. the need to mention outcome not available if relevant
3. some of the remediation is specific, some of it isn't. Need to figure out what @laurentsimon wants in terms of level of detail.

In terms of the implementations, there's a huge amount of code duplication problem. This is mainly targeted at the ones whose existence is just a bool pointer. They can be extracted to some helper to cut down on duplication. Some of these checks have more complicated scenarios, so I realize they won't use the helper.

In terms of testing, I prefer the names reflect the behavior being tested, not describing the test. In general, this had to do with the OutcomeNotAvailable not being reflected in the testname, and the test was doing more than one thing.

[AdamKorcz]

In terms of the implementations, there's a huge amount of code duplication problem. This is mainly targeted at the ones whose existence is just a bool pointer. They can be extracted to some helper to cut down on duplication. Some of these checks have more complicated scenarios, so I realize they won't use the helper.

I added this helper here: dd371e3. WDYT?

[spencerschrock]

there may be some polish needed, but since it's not hooked up at this point, we'll have to wait until merge and next PR.

Just to be explicit, do you plan on doing the PR required probe in this one? a separate PR? or in the connecting PR?

[AdamKorcz]

do you plan on doing the PR required probe in this one? a separate PR? or in the connecting PR?

In a separate PR.