In commit 6006acc in PR git-lfs#976 we
introduced a conditional build clause to the SPEC file use we to
build RPM Linux packages, in an attempt to avoid compiling with
cgo enabled on Red Hat Enterprise Linux (RHEL) 5 and CentOS 5
platforms.  This change was made after the use of the "C" pseudo-
module was introduced into the Git LFS client code in commit
ea16fd5 of PR git-lfs#952, as part of
our initial support for copy-on-write file creation.

In practice, though, this conditional build clause was ineffective,
according to the notes in PR git-lfs#976.  Instead, one of the Dockerfiles
used to build RPM packages for the RHEL/CentOS 5 platform was updated
in commit git-lfs/build-dockers@39cec36
of PR git-lfs/build-dockers#1 to set the CGO_ENABLED environment
variable with a value of "0".

The conditional build clause in our SPEC file was never removed
afterwards, however.  Later, the Dockerfile in which the CGO_ENABLED
environment variable was set was removed in commit
git-lfs/build-dockers@d4c2fe6,
and the primary Dockerfile used for building packages for the
RHEL/CentOS 5 platform was then dropped in commit
git-lfs/build-dockers@64a3a9f
of PR #3.  This followed the removal of the references to the
RHEL/CentOS 5 platform from the scripts in our "dockers" directory in
commit b560b85 of PR git-lfs#1298.

As there is no value to retaining the conditional build clause
for the RHEL/CentOS 5 platform in the SPEC file for our RPM packages,
we simply remove it now.

When we build Debian and RPM Linux packages, we define the minimum
versions of Git and Go required by the Git LFS client.  However,
the minimum versions we specify are at present somewhat out of date.

Specifically, both the "control" file for our Debian packages and the
SPEC file for our RPM packages state that we require at least Git
version 1.8.2, and the former also specifies that we require at least
Go version 1.12.0.

In practice, though, since we introduced the "git lfs migrate" command
in PR git-lfs#2353, Git v2.0.0 has been the earliest version of Git we support,
as per commit 5aea841 of that PR.

We have also required at least Go v1.23.0 to build the Git LFS client
since commit 70e23fa of PR git-lfs#5997,
when we updated the minimum version of the x/crypto Go module specified
in our "go.mod" file and the "go mod tidy" command then also updated
the minimum required version of Go to 1.23.0.

Because we anticipate making a v3.7.0 release of the Git LFS client in
the near future, we now update the "control" file for our Debian
packages and the SPEC file for our RPM packages to indicate that
the Git LFS client requires at least Git v2.0.0 and Go v1.23.0.

As announced with the v3.6.0 release of the Git LFS client, and as
noted in commit 23fbfe8 of PR git-lfs#5911,
since all the distribution versions based on Red Hat Enterprise Linux
(RHEL) 7, CentOS 7, and SUSE Linux Enterprise Server (SLES) 12 for which
we previously built RPM packages have now reached the end of their
standard LTS (Long-Term Support) periods, future releases of Git LFS
will no longer provide support for these platforms or build packages
for them.

Because we anticipate making a v3.7.0 release of the Git LFS client in
the near future, we removed the Dockerfile we used to build packages
for the RHEL/CentOS 7 and SLES 12 platforms in commit
git-lfs/build-dockers@cfde130 of
PR git-lfs/build-dockers#71.

We can now also remove the entries for these platforms from the list
of our supported Linux distribution versions in the DistroMap Ruby
class source file, which is utilized by several scripts run by our
GitHub Actions release workflow jobs when building and naming the
Linux packages we publish on Packagecloud.

As announced with the v3.6.0 release of the Git LFS client, and as
noted in commit 23fbfe8 of PR git-lfs#5911,
since all the distribution versions based on Debian 10 ("buster")
for which we previously built Debian packages have now reached the
end of their standard LTS (Long-Term Support) periods, future releases
of Git LFS will no longer provide support for this platform or build
packages for it.

Because we anticipate making a v3.7.0 release of the Git LFS client in
the near future, we removed the Dockerfile we used to build packages
for the Debian 10 platform in commit
git-lfs/build-dockers@04829f9 of
PR git-lfs/build-dockers#71.

We can now also remove the entries for this platform from the list
of our supported Linux distribution versions in the DistroMap Ruby
class source file, which is utilized by several scripts run by our
GitHub Actions release workflow jobs when building and naming the
Linux packages we publish on Packagecloud.

Rocky Linux 10.0 was recently released, following the release last month
of RHEL (Red Hat Enterprise Linux) 10.0, and because we anticipate making
a v3.7.0 release of the Git LFS client in the near future, we added a
Dockerfile we can use to build packages for the RHEL/Rocky Linux 10
platform in commit
git-lfs/build-dockers@cc16329 of
PR git-lfs/build-dockers#71.

We can now also add entries for this platform to the list of our
supported Linux distribution versions in the DistroMap Ruby class
source file, which is utilized by several scripts run by our
GitHub Actions release workflow jobs when building and naming the
Linux packages we publish on Packagecloud.

We maintain a compatibility matrix of Linux distributions and versions
in the DistroMap Ruby class in our script/lib/distro.rb source file,
which is utilized by several scripts run by our GitHub Actions release
workflow jobs when building and naming the Linux packages we publish
on Packagecloud.

As we anticipate making a v3.7.0 release of the Git LFS client in
the near future, we first update the list of Linux distribution
versions for which we will build RPM and Debian packages, removing
those which have reached the end of their regular support lifecycles
and adding those which have become available since our v3.6.0 release.

As announced with the v3.6.0 release of the Git LFS client, and as
noted in commit 23fbfe8 of PR git-lfs#5911,
since all the distribution versions based on Red Hat Enterprise Linux
(RHEL) 7, CentOS 7, and SUSE Linux Enterprise Server (SLES) 12 for which
we previously built RPM packages have now reached the end of their
standard LTS (Long-Term Support) periods, future releases of Git LFS
will no longer provide support for these platforms or build packages
for them.

Because we anticipate making a v3.7.0 release of the Git LFS client in
the near future, we removed the Dockerfile we used to build packages
for the RHEL/CentOS 7 and SLES 12 platforms in commit
git-lfs/build-dockers@cfde130 of
PR git-lfs/build-dockers#71.  We then also removed the entries for
these platforms from the list of our supported Linux distribution
versions in the DistroMap Ruby class source file, which is utilized
by several scripts run by our GitHub Actions release workflow jobs
when building and naming the Linux packages we publish on Packagecloud.

Previously, we removed support for the RHEL/CentOS 6 platform in
commit d69e28d in PR git-lfs#4328.

However, our "docker/run_dockers.bsh" shell script still references
these platforms in its comments, so we update that script now to
provide more up-to-date usage examples.

As well, we update the test data in the Ruby RSpec script we use to
validate the DistroMap Ruby class source file, so that the test data
now aligns more closely with our current list of supported Linux
distribution versions.  Note, though, that this change does not affect
the behaviour of either the test script or the DistroMap source file.

In PR git-lfs#5054 we updated the source files of our manual pages from the
Ronn format to the AsciiDoc format, which necessitated changing our
Linux package build processes to use the Asciidoctor Ruby gem to
generate manual pages in Roff and HTML formats.

At the time, an RPM package for a 2.0.x version of the Asciidoctor
Ruby gem was not easily available for all the platforms based on Red Hat
Enterprise Linux (RHEL) that we supported, particularly RHEL/CentOS 7,
so in commit db9a821 of PR git-lfs#5054 we
updated the "rpm/build_rpms.bsh" script to build and install a custom RPM
package with Asciidoctor v2.0.17.  In the same commit we also defined
a SPEC file for this custom rubygem-asciidoctor RPM package in the
"rpm/SPECS" directory.

However, we have now removed the Dockerfile we used to build packages
for the RHEL/CentOS 7 and SLES 12 platforms in commit
git-lfs/build-dockers@cfde130 of
PR git-lfs/build-dockers#71, because all the distribution versions
based on RHEL 7, CentOS 7, and SUSE Linux Enterprise Server (SLES) 12
for which we previously built RPM packages have now reached the end
of their standard LTS (Long-Term Support) periods, and so future releases
of the Git LFS client will no longer build packages for them.

Further, in PR git-lfs/build-dockers#73 we updated the Dockerfiles
we use to build RPM packages of the Git LFS client on the
RHEL/CentOS 8, RHEL/Rocky Linux 9, and RHEL/Rocky Linux 10 platforms
so that the rubygem-asciidoctor package is installed before the
final command in the Dockerfiles is run.  This rubygem-asciidoctor
package provides Asciidoctor v2.0.15 or higher, so we no longer
need to build and install a custom RPM package in order to use
Asciidoctor to generate manual pages formatted in Roff and HTML.

We can therefore now delete our custom SPEC file for the
rubygem-asciidoctor package, and also simplify our "rpm/build_rpms.bsh"
script by removing the section which built and installed our custom
RPM package if the "asciidoctor" command was not found in a given
Docker container image for an RHEL-based platform.

In commit e4e5ada of PR git-lfs#5882 we
added an initial check to the t/t-clone.sh test script which detects
whether libcurl is linked against the legacy libnss3 library on Linux,
and if so, sets a GIT_LIBNSS variable.  We then check that variable
at the start of several tests in the script, and if it is set, skip
performing the tests.

This workaround was introduced because the libnss3 library rejects
TLS/SSL certificates which have both an Extended Key Usage attribute
for TLS Web Server Authentication and a Basic Constraint setting of
"CA:TRUE", and the self-signed certificate used by our lfstest-gitserver
utility program has both attributes, so our tests would otherwise fail.

The only platform on which our tests run which used the legacy libnss3
library was the one based on Red Hat Enterprise Linux (RHEL) 7.  All
the distribution versions based on RHEL 7, CentOS 7, and SUSE Linux
Enterprise Server (SLES) 12 for which we previously built RPM packages
have now reached the end of their standard LTS (Long-Term Support)
periods, and so future releases of the Git LFS client will no longer
build packages for them.

We therefore removed the Dockerfile we used to build packages for the
RHEL/CentOS 7 and SLES 12 platforms in commit
git-lfs/build-dockers@cfde130 of
PR git-lfs/build-dockers#71.  As well, in a prior commit in this PR
we removed the entries for these platforms from the list of our
supported Linux distribution versions in the DistroMap Ruby class
source file, which is utilized by several scripts run by our GitHub
Actions CI and release workflow jobs.

Since our CI and release workflows will no longer run on any platforms
where libcurl is linked against the legacy libnss3 library, we can now
also remove the checks for the libnss3 library from our t/t-clone.sh
test script.