Since PR git-lfs#3840 introduced a GitHub Actions workflow to automate much
of the process of releasing a new version of Git LFS, that workflow
has concluded by running the script/upload script, which makes requests
to GitHub's API to create a new draft release announcement and attach
the binary release assets built by the workflow to the announcement.

This step necessarily requires that the GITHUB_TOKEN credential provided
to the workflow have permission to create a release, which implies
fairly broad write access to the repository contents as GitHub does
not offer a more fine-grained permission model for this particular task.

In order to ensure that our GitHub Actions workflows can not be
misused, we would much prefer to run them without write permissions to
our repositories.  We therefore revise the "build-main" job in our
release workflow to remove the step which tries to run the script/upload
script, and replace it with steps that instead create a "release-assets"
artifact containing the binary release assets built by the workflow.

The administrator performing the release may then download this artifact
and unpack it, after which they can run the script/upload script manually
using their own personal GitHub credentials.  We update our release
process documentation to explain this new approach and also clarify a
few other details of the release process.

This change does make our release process slightly more manual, and
if in the future GitHub provides a convenient way to enable a single
job to have just sufficient permissions to create a draft release
announcement, we can revisit this decision in the future.

In commit bfc5304 of PR git-lfs#4143 we
introduced a set of Makefile targets which sign and notarize binaries
on macOS using the "codesign" and "security" utilities, among others.
The recipes for these targets create a new, dedicated keychain and
add our Apple Developer ID certificate to it, and then use the keychain
to sign the macOS binaries we build.

Although we refer to this keychain in some commands using the Makefile
variable DARWIN_KEYCHAIN_ID, whose default is the value "CI.keychain",
in other commands we refer to that keychain name explicitly.  As a
consequence, the variable can not actually be set to something other
than its default value without causing problems.

As we expect to further revise some of these Makefile targets in
subsequent commits in this PR, we first adjust their recipes to
use the DARWIN_KEYCHAIN_ID variable consistently, and we also take
the opportunity to alter its default value to "lfs.keychain", since
we run these recipes in both our CI and release GitHub Actions
workflows, not just in the CI workflow.

In commit bfc5304 of PR git-lfs#4143 we
introduced a set of Makefile targets which sign and notarize binaries
on macOS using the "codesign" and "security" utilities, among other
tools.  The recipes for these targets create a new, dedicated keychain
and add our Apple Developer ID certificate to it, and then use the
keychain to sign the macOS binaries we build.

These recipes include several commands which generate a considerable
amount of detailed diagnostic log output, making the logs somewhat
difficult to read.  We can clarify the steps involved in the signing
process by adding several log statements, removing commands which
only generate extra diagnostics, and silencing the output of others.

If we encounter problems with the macOS signing process in the
future, we can always reinstate these commands while running the
Makefile recipes on a local machine or in a private repository
in order to trace the source of the issues.

In commit bfc5304 of PR git-lfs#4143 we
introduced a set of Makefile targets which sign and notarize binaries
on macOS using the "codesign" and "security" utilities, among other
tools.  The recipes for these targets create a new, dedicated keychain
and add our Apple Developer ID certificate to it, and then use the
keychain to sign the macOS binaries we build.

At present, we retrieve our Apple Developer ID certificate and password
from GitHub Actions secrets, along with our Developer ID signing identity,
which is provided in an Actions secret named MACOS_CERT_ID.  We then pass
that identity to the "codesign" command with the -s option (i.e., the
--sign option) in order to sign our binary release assets.

In a subsequent commit in this PR we will modify our release GitHub
Actions workflow to retrieve the certificate data from a new system,
as our current Apple Developer ID certificate expired recently and
can not simply be renewed.  This new system to manage Apple Developer
ID certificates does not provide the signing identity in an Actions
secret, just the certificate and password.

Fortunately, we can retrieve the signing identity from the local macOS
keychain we have created in the recipe for our "release-import-certificate"
Makefile target, using the "find-identity" subcommand of the "security"
command, so we do that now at the start of our "release-darwin" target's
recipe.

This in turn allows us to remove the DARWIN_CERT_ID variable from our
Makefile and update our release workflow as it no longer needs to set
that environment variable from the MACOS_CERT_ID Actions secret.

In commit bfc5304 of PR git-lfs#4143 we
introduced a set of Makefile targets which sign and notarize binaries
on macOS using the "codesign" and "security" utilities, among other
tools.  The recipes for these targets create a new, dedicated keychain
and add our Apple Developer ID certificate to it, and then use the
keychain to sign the macOS binaries we build.

Our most recent certificate expired recently, and per the current
Apple documentation, a maximum of five certificates are permitted
for each Apple Developer ID:

  You can create up to five Developer ID Application certificates and
  up to five Developer ID Installer certificates using either your
  developer account or Xcode.

  https://developer.apple.com/help/account/create-certificates/create-developer-id-certificates

As our Developer ID is provided to us by GitHub, and they distribute
multiple other projects which also need to be signed, we are no longer
able to use a certificate dedicated just to Git LFS, and so need to
adopt GitHub's process for managing these certificates.  To do so we
alter our release GitHub Actions workflow to retrieve the necessary
certificate and password from the Actions secrets provided by GitHub's
internal tooling.  This tool makes the certificate data available in
Actions environment secrets using an environment named "production",
so we add that environment to most of the jobs in our release workflow.

When we push a new release tag and our release workflow is enqueued,
it will now wait to begin running these jobs until we manually validate
the workflow in GitHub's Apple Developer ID certificate management
interface, so we add that step to our release process documentation.

Note that we exclude the "build-main" job in our release workflow
from the "production" environment because it runs only after the
"build-macos" and "build-windows" jobs are complete, and if it ran
in the "production" environment it would therefore require a second
manual validation in the GitHub certificate management tool.  As this
would be inconvenient and unnecessary, we just allow the job to run
in the default environment.

In the "build-docker" and "build-docker-cross" jobs in our CI GitHub
Actions workflow we currently install Ruby using the ruby/setup-ruby
action, which has been true since we introduced the first of these
jobs in commit 212c051 of PR git-lfs#3932.

However, unlike the corresponding jobs in our release workflow, where
we need the Ruby interpreter in order to run our script/packagecloud.rb
utility at the end of the job, we do not actually require Ruby for the
CI versions of these jobs, so we can simply remove the ruby/setup-ruby
step from them now.

In commit 0044d78 of PR git-lfs#4728 we
added the "build-docker-cross" job both our CI and release GitHub
Actions workflows in order to build Debian Linux packages of Git LFS
on the ARM64 platform.  We only build an ARM64 package for Debian 12
because the build process is very slow, as we have had to use the
Quick Emulator (QEMU) on AMD64 (x86_64) runners.

Lately, some of these CI jobs have failed due to segmentation faults
reported from the gcc compiler when it attempts to compile various
modules from the Go standard packages.  These failures appear to be
unrelated to any changes in our code, but may be due to issues with
the ARM64 emulation or some other dependency.

Fortunately, GitHub has recently made ARM64 Actions runners available
for use in public repositories like ours:

  https://github.com/orgs/community/discussions/148648

This means we can simply replace our "build-docker-cross" jobs with
"build-docker-arm" jobs that utilize the ARM64 runners, and which do
not exhibit the same kinds of failures with the gcc compiler.

The build time for these new jobs is significantly faster than the old
ones which ran in emulation, to the point where it now becomes feasible
for us to build a Debian 11 package as well as the Debian 12 one.
(We skip building a Debian 10 package since we expect to drop support
for that platform fairly soon.)

We should also be able to build an RPM package for ARM64 using Rocky 9,
once we make some updates to our RPM package metadata files and the
corresponding Dockerfile in our git-lfs/build-dockers repository.
For the time being, however, we defer these changes to future PRs.