capsicum-test: Move out of contrib

[emaste]

Summary

Google developed the Capsicum unit test suite[1] as part of the
Capsicum-Linux[2] project, based on unit tests that existed in FreeBSD
and unit tests developed as part of the initial capsicum-Linux port.

Capsicum-Linux was archived as of October 31, 2022 and is no longer
being maintained, and FreeBSD is currently the only consumer of and
contributor to the test suite.  Move the test src into
tests/sys/capsicum to simplify maintenance.

The makefiles were deleted as we (continue to) use the existing FreeBSD
Makefile, and CONTRIBUTING.md was removed as the Google CLA no longer
applies.

[1] https://github.com/google/capsicum-test
[2] https://github.com/google/capsicum-linux

@drysdale_google.com I think we can do this and then archive https://github.com/google/capsicum-test. If that makes sense to you I can submit a pull request to update the README.md in the capsicum-test repo referencing the new location before archiving the repo.

I've kept capsicum-linux.h and linux.cc across the move.

[oshogbo]

I like this idea. Thank you.

[emaste]

Two open pull requests:
https://github.com/google/capsicum-test/pull/35 - Fix OpenatTest.WithFlag when O_BENEATH is passed after 5eb909a37339fe4675ef95b769a07c5eb3894799
https://github.com/google/capsicum-test/pull/40 - Separate out differing O_BENEATH behaviours
Three open issues:
https://github.com/google/capsicum-test/issues/27 - OpenatTest.* failures if vfs.lookup_cap_dotdot is disabled
https://github.com/google/capsicum-test/issues/28 - OpenatTest.WithFlag / ForkedOpenatTest_WithFlagInCapabilityMode._ fail fails on FreeBSD
https://github.com/google/capsicum-test/issues/60 - sctp.cc's #ifdef HAVE_SCTP is not functional on FreeBSD

#60 is already resolved in the FreeBSD tree. We can revisit the others afterwards.

[ngie]

Does it make sense for FreeBSD to adopt the repo and maintain the component upstream like that :/?
Also, IANAL, but can we just delete the Google stuff without a Google lawyer barking at us about doing that? This comment also applies to @jmmv's other projects, I guess..

[emaste]

Does it make sense for FreeBSD to adopt the repo and maintain the component upstream like that :/?

I don't see any reason to do that, it keeps the overhead of having a separate upstream to manage, without providing any benefit (as nobody else will be using it). If someone revives the Capsicum-Linux effort or ports to another operating system we can split this out again.

Also, IANAL, but can we just delete the Google stuff without a Google lawyer barking at us about doing that? This comment also applies to @jmmv's other projects, I guess..

We're not removing any Google license or terms, just the reference to the Google CLA which does not apply to changes in our tree.

[asomers]

I agree with Ed on all of these points.

[emaste]

Will push after stabweek concludes