According to the Go release policy[1], only the two most recent
releases are supported:

  Each major Go release is supported until there are two newer
  major releases. For example, Go 1.5 was supported until the
  Go 1.7 release, and Go 1.6 was supported until the Go 1.8
  release. We fix critical problems, including critical
  security problems, in supported releases as needed by
  issuing minor revisions (for example, Go 1.6.1, Go 1.6.2,
  and so on).

... and with Go v1.18 being the most recent major release, trim the
Go versions to the two supported 1.18.x and 1.17.x, leaving 1.16.x
as it remains part of the GH Ubuntu 20.04 environment even though
it is officially unsupported.  Go 1.15.x is dropped from the test
matrix.

We also update the core libseccomp library to the latest v2.5.x
release, which is v2.5.4 as of April 21, 2022.  The previous
libseccomp versions are left untouched in the test matrix, even
though they are no longer supported upstream.

[1] https://go.dev/doc/devel/release#policy

Acked-by: Tom Hromatka <[email protected]>
Acked-by: Kir Kolyshkin <[email protected]>
Signed-off-by: Paul Moore <[email protected]>

As per #87

Signed-off-by: Kir Kolyshkin <[email protected]>
Signed-off-by: Paul Moore <[email protected]>

Bumps:

 * Update actions/checkout, actions/setup-go,
   golangci/golangci-lint-action from v2 to v3.

 * Bump golangci-lint to v1.45.

Cleanups:

 * Remove "stable" parameter for setup-go (not needed since v3,
   see [1]).

 * Remove the obsoleted comment for golangci-lint (no longer
   true, see [2]).

[1] https://github.com/actions/setup-go/releases/tag/v3.0.0
[2] golangci/golangci-lint-action#167

Signed-off-by: Kir Kolyshkin <[email protected]>
Acked-by: Paul Moore <[email protected]>
Signed-off-by: Tom Hromatka <[email protected]>

The mailing list has been deprecated and made read-only, remove
references from the README.md file.

Acked-by: Tom Hromatka <[email protected]>
Signed-off-by: Paul Moore <[email protected]>

Update our release process and README documentation based on our
current plans.  These docs can (and should!) be updated as needed to
reflect changes in our processes.

Acked-by: Tom Hromatka <[email protected]>
Signed-off-by: Paul Moore <[email protected]>

Signed-off-by: Paul Moore <[email protected]>

Whenever we do not return the error code from a libseccomp call
directly, embed it into our error (via %w), so that a user can still
check for it using something like errors.Is(err, syscall.EINVAL).

Acked-by: Tom Hromatka <[email protected]>
Signed-off-by: Kir Kolyshkin <[email protected]>

In case seccomp_api_set() failed, embed its return code into the error
(rather than merely adding -N text into it), so that a user can check
for a particular error using e.g. errors.Is(err, syscall.EINVAL).

Do not embed EOPNOTSUPP since this is not what libseccomp returns
(this is returned by own code in case it is compiled with old (< 2.4.0)
libseccomp headers).

Acked-by: Tom Hromatka <[email protected]>
Signed-off-by: Kir Kolyshkin <[email protected]>

If there are no %-style directives, using errors.New is preferable.

Acked-by: Tom Hromatka <[email protected]>
Signed-off-by: Kir Kolyshkin <[email protected]>

Acked-by: Paul Moore <[email protected]>
Acked-by: Tom Hromatka <[email protected]>
Signed-off-by: Kir Kolyshkin <[email protected]>