maint: release process updates for friendlier ARNs

[robbkidd]

Which problem is this PR solving?

Release woes, enumerated below with the changes.

Short description of the changes

Reorganize releasing

• Closes Rename executable artifact from amd64 to x86_64 #82
• Rename published layer in regions to honeycomb-lambda-extension-<arch>-<version tag> so that our layer versions will always be :1
• Some changes in service towards produce json of release info when publishing #95, but not fully producing a release.json yet

Make is good at knowing how to make files. This moves the layer contents
zip creation from the publish script to the Makefile. There's some duplication,
but I think that keeps the Making more readable. CI updated to use the zip
make target to build the binaries and the zip files for artifact storage and
workflow pass-along.

Publish script updated to record the results of AWS API calls to files instead of
to script variables or the console. With the results recorded on the filesystem,
we can see success/failures after the fact and thereby build release.json from
the data in the API responses.

Use the CIRCLE_TAG as the version for a build

• Closes user-agent based on actual published version number #66

Include the build version in the user-agent (formatting updated to spec).

If the CI workflow doesn't have a tag, default to an informative version
derived from the current state of the git repository. For example, this
git describe command returns the following from the branch this commit
will land on:

» git describe --always --tags --match "v[0-9]*" HEAD
v10.3.0-9-g834dbcb

Which is:

• the nearest tag in history that matches the pattern
• the number of commits the branch's HEAD is away from that tag/commit
• g + the sha of current HEAD

Test against only a single Go version

• Closes Test against only the one Go version the layer is built against #100

This is a project released and consumed as a binary. We only need to test
against the version of Go we build and release with.

[robbkidd]

Showing my work on determining this new list.

• Copied the <ul> lists of x86_64 and arm64 supporting regions from the AWS Lambda pricing page. (ಠ_ಠ)
• Trimmed the content down from the HTML to only the region identifiers in those lists.
• Diff'd the lists.

» diff --ignore-matching-lines --side-by-side regions-arm64.txt regions-x86_64.txt
16a17
> me-central-1
20a22,23
> us-gov-east-1
> us-gov-west-1

(fuller diff)

 » diff --side-by-side regions-arm64.txt regions-x86_64.txt
af-south-1							af-south-1
ap-east-1							ap-east-1
ap-northeast-1							ap-northeast-1
ap-northeast-2							ap-northeast-2
ap-northeast-3							ap-northeast-3
ap-south-1							ap-south-1
ap-southeast-1							ap-southeast-1
ap-southeast-2							ap-southeast-2
ap-southeast-3							ap-southeast-3
ca-central-1							ca-central-1
eu-central-1							eu-central-1
eu-north-1							eu-north-1
eu-south-1							eu-south-1
eu-west-1							eu-west-1
eu-west-2							eu-west-2
eu-west-3							eu-west-3
							      >	me-central-1
me-south-1							me-south-1
sa-east-1							sa-east-1
us-east-1							us-east-1
us-east-2							us-east-2
							      >	us-gov-east-1
							      >	us-gov-west-1
us-west-1							us-west-1
us-west-2							us-west-2

OK. Only Middle East (UAE) and GovCloud in the x86_64-only camp.

How does the new list of regions with arm64 support compare with our previous lists? They match.

irb> NEW_REGIONS_WITH_ARM64 == (REGIONS_NO_ARCH + REGIONS_WITH_ARCH)
=> true

Details: Set comparisons with Ruby

# Because Ruby is a tool near to my hand …
» irb
irb(main):001:1] REGIONS_NO_ARCH=Set.new(%w[eu-north-1 us-west-1 eu-west-3 ap-northeast-2 sa-east-1 ca-central-1 af-south-1
irb(main):002:1]                 ap-east-1 eu-south-1 me-south-1 ap-southeast-3 ap-northeast-3])
=>
#<Set:
...
irb(main):003:1] REGIONS_WITH_ARCH=Set.new(%w[ap-south-1 eu-west-2 us-east-1 eu-west-1 ap-northeast-1 ap-southeast-1
irb(main):004:1]                    ap-southeast-2 eu-central-1 us-east-2 us-west-2])
=> #<Set: {"ap-south-1", "eu-west-2", "us-east-1", "eu-west-1", "ap-northeast-1", "ap-southeast-1", "ap-southeast-2", "eu-central-1", "us-east-2", "us-west-2"}>
irb(main):005:1] NEW_REGIONS_WITH_ARM64=Set.new(%w[
irb(main):006:1]   af-south-1
irb(main):007:1]   ap-east-1
irb(main):008:1]   ap-northeast-1
irb(main):009:1]   ap-northeast-2
irb(main):010:1]   ap-northeast-3
irb(main):011:1]   ap-south-1
irb(main):012:1]   ap-southeast-1
irb(main):013:1]   ap-southeast-2
irb(main):014:1]   ap-southeast-3
irb(main):015:1]   ca-central-1
irb(main):016:1]   eu-central-1
irb(main):017:1]   eu-north-1
irb(main):018:1]   eu-south-1
irb(main):019:1]   eu-west-1
irb(main):020:1]   eu-west-2
irb(main):021:1]   eu-west-3
irb(main):022:1]   me-south-1
irb(main):023:1]   sa-east-1
irb(main):024:1]   us-east-1
irb(main):025:1]   us-east-2
irb(main):026:1]   us-west-1
irb(main):027:1]   us-west-2])
=>
#<Set:
...
irb(main):028:0> NEW_REGIONS_WITH_ARM64 == (REGIONS_NO_ARCH + REGIONS_WITH_ARCH)
=> true

[robbkidd]

The layer name changes in this PR (and all subsequent releases!). That's a change users will need to adjust for, but even so I don't think the release version number needs a major version bump. I think we can make the new situation known in release notes that the ARN for the layer version is more dramatically different than an increased layer version number. Which I suspect users would notice if they went to look up the latest layer version and see that it went from 11 to 1.

[robbkidd]

We'll need to do the role permissions grant to publish in Middle East (UAE) before adding this region to the x86_64 only list.

[JamieDanielson]

We went through the whole process with a dev tag, this seems to be in good shape!

[robbkidd]

Opting to major version bump to draw attention to the new layer naming scheme.