release-22.2: build-and-publish-patched-go: upgrade from 1.19.1 to 1.19.4

[rickystewart]

Backport 1/1 commits from #93852.

/cc @cockroachdb/release

Release justification: pick up security/compiler fixes from upstream Go

---

This picks up a mix of security and compiler fixes. The compiler fixes I'm interested in relate to generic data structures, but the other fixes seem worthwhile too.

• Adjust the Pebble tests to run in new version.
• Adjust version in Docker image (source).
• Adjust version in the TeamCity agent image (setup script)
• Rebuild and push the Docker image (following Basic Process)
• Update build/teamcity/internal/release/build-and-publish-patched-go/impl.sh with the new version and adjust SHA256 sums as necessary.
• Run the Internal / Release / Build and Publish Patched Go build configuration in TeamCity with your latest version of the script above. This will print out the new URL's and SHA256 sums for the patched Go that you built above.
• Bump the version in WORKSPACE under go_download_sdk. You may need to bump rules_go. Also edit the filenames listed in sdks and update all the hashes to match what you built in the step above.
• Run ./dev generate bazel to refresh distdir_files.bzl, then bazel fetch @distdir//:archives to ensure you've updated all hashes to the correct value.
• Bump the version in builder.sh accordingly (source).
• Bump the version in go-version-check.sh (source), unless bumping to a new patch release.
• Bump the go version in go.mod.
• Bump the default installed version of Go in bootstrap-debian.sh (source).
• Replace other mentions of the older version of go (grep for golang:<old_version> and go<old_version>).
• Update the builder.dockerImage parameter in the TeamCity Cockroach and Internal projects.
• Ask the Developer Infrastructure team to deploy new TeamCity agent images according to packer/README.md

Epic: None

Release note: None

[blathers-crl]

Thanks for opening a backport.

Please check the backport criteria before merging:

• Patches should only be created for serious issues or test-only changes.
• Patches should not break backwards-compatibility.
• Patches should change as little code as possible.
• Patches should not change on-disk formats or node communication protocols.
• Patches should not add new functionality.
• Patches must not add, edit, or otherwise modify cluster versions; or add version gates.

If some of the basic criteria cannot be satisfied, ensure that the exceptional criteria are satisfied within.

• There is a high priority need for the functionality that cannot wait until the next release and is difficult to address in another way.
• The new functionality is additive-only and only runs for clusters which have specifically “opted in” to it (e.g. by a cluster setting).
• New code is protected by a conditional check that is trivial to verify and ensures that it only runs for opt-in clusters.
• The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.

Add a brief release justification to the body of your PR to justify this backport.

Some other things to consider:

• What did we do to ensure that a user that doesn’t know & care about this backport, has no idea that it happened?
• Will this work in a cluster of mixed patch versions? Did we test that?
• If a user upgrades a patch version, uses this feature, and then downgrades, what happens?

[cockroach-teamcity]

This change is