[FEATURE] Automate Releases

[Kern--]

Is your feature request related to a problem? Please describe.
As we start thinking about releasing binaries of the SOCI snapshotter, it would be good to start thinking about how to make the process repeatable to make sure we don't miss an artifacts or details.

Describe the solution you'd like
Ideally we would have a github actions pipeline that automatically created a github release with all the relevant artifacts whenever we push a tag.

Describe alternatives you've considered
N/A

Additional context
References:
Containerd's workflow https://github.com/containerd/containerd/blob/main/.github/workflows/release.yml
nerdctl's workflow https://github.com/containerd/nerdctl/blob/main/.github/workflows/release.yml

[Kern--]

Another reference is the way Finch is doing it:
https://github.com/runfinch/finch/blob/main/.github/workflows/release-please.yaml

In particular they use release please to automate the releases including generating the changelog.

[Kern--]

Our branching strategy is defined here: https://github.com/awslabs/soci-snapshotter/blob/main/RELEASES.md#releases-1
The release artifacts are defined here: https://github.com/awslabs/soci-snapshotter/blob/main/RELEASES.md#release-artifacts

The last piece is the actual process which is:

1. Create the branch if necessary
2. Use scripts/build_third_party_licenses.sh to create the final third party licenses file. Commit it and open a PR to merge it into the release branch.
3. Create and push signed tag against the license file commit
4. Automation should take over here and create the releases according to our documentation.
5. [Maybe] Update the release change log if we take an approach like nerdctl which doesn't generate it automatically

We should probably add this documentation somewhere, but not in the releases doc because these instructions are things that only maintainers care about.

[djdongjin]

fyi: nerdctl's new release doc for maintainers: https://github.com/containerd/nerdctl/blob/main/MAINTAINERS_GUIDE.md

[Kern--]

A couple more notes that should go into the maintainer's version of the release doc:

1. I've been using ubuntu 18.04 when building dynamically linked binaries so that the glibc version is "relatively old" and likely to work for most people.
2. I've been building with the latest version of go at the time of the release.
3. The tag needs to be created before building so that the binary version reports correctly
4. I verify that the static binaries are actually static with ldd.

[sparr]

I've been building with the latest version of go at the time of the release.

Should we instead be building with the version in our go.mod (currently 1.18(.latest))? Or the version in our github workflows (currently 1.18.10)?

[Kern--]

Should we instead be building with the version in our go.mod?

Possibly? The go directive in go.mod has really weird semantics. A lot of people interpret it as the "minimum supported go version", which isn't really what it means but it's more-or-less how we're using it.

The reason to use a newer version is because we might get not-yet-backported bug fixes or standard library improvements.

[sondavidb]

#876 takes care of the AMD64 side. ARM64 remains largely un-automated, though that PR also helps make that process a bit easier. We should keep this open as other options for ARM64 become available/known.