Cirrus-CI: Add a task to check housekeeping state

[brooks]

Summary

This task runs in parallel to the builds and checks for things requiring
manual housekeeping. There three sets of tests:

• make sysent: make sure that any changes that cause make sysent to produce changes include a commit to update the generated files.
• check-ldirs: verify that directories search for includes to install actually exist.
• makeman: when option configurations change, src.conf.5 needs to be updated and (sometimes) new WITH(OUT)_OPTION descriptions need to be added to tools/build/options. Check for both of these conditions.

Sponsored by: DARPA

[brooks]

Fix typo

[brooks]

Actually committing depends on adding the missing descriptions in D38961 as well as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270017.

Example failures (plus a bunch of debugging crap) can be seen in https://cirrus-ci.com/github/brooksdavis/freebsd/more-cirrus-jobs

[emaste]

Do we expect that the src.conf.5/generated sysent files will be included in the same commit, or that one should stage two commits locally for one push? (We should probably document that somewhere, afaik src.conf.5 and sysent are primarily lore at this point)

[brooks]

In D38991#887515, @emaste wrote:

Do we expect that the src.conf.5/generated sysent files will be included in the same commit, or that one should stage two commits locally for one push? (We should probably document that somewhere, afaik src.conf.5 and sysent are primarily lore at this point)

Either works with this check. I somewhat prefer a single commit to limit broken commits in bisection (if you get a conflict on MFC that reminds you to make the update), but at least one committer is strongly opposed.

[brooks]

• Recase as housekeeping rather than generated file
• Check that L*DIRS exist in include/Makefile

[emaste]

One question I have is whether this will reduce throughput if we end up running into the open source Cirrus-CI concurrency limit (2 VMs at a time). We could also avoid these on private branches perhaps to avoid that.

[brooks]

It looks like limits are now based on CPU cores per VM type https://cirrus-ci.org/faq/#are-there-any-limits (though were GCP instances fit in to that I'm not entirely sure.). I do see the job is stuck behind the main one so maybe we should just put theses scripts in the main job (perhaps limiting makeman to one architecture).

Half serious suggestion: Maybe we could rework the main tasks to run on the 12-core MacOS workers...

[brooks]

Replaced by D39680 D39681 D39682. Concurrency limits make this not work well.