[release-15.0] Use go1.19.3 in the upgrade/downgrade tests

[frouioui]

Description

This Pull Request changes the ugprade downgrade tests to use go1.19.3. Since we bumped the version on main (#11655) we need to use the proper golang version in the tests that uses main.

Related Issue(s)

• Fixes Make sure the Go version on release-15.0 upgrade/downgrade tests matches the one used in main #11657

Checklist

• "Backport me!" label has been added if this change should be backported
• Tests were added or are not required
• Documentation was added or is not required

Deployment Notes

[vitess-bot]

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• If this is a change that users need to know about, please apply the release notes (needs details) label so that merging is blocked unless the summary release notes document is included.

If a new flag is being introduced:

• Is it really necessary to add this flag?
• Flag names should be clear and intuitive (as far as possible)
• Help text should be descriptive.
• Flag names should use dashes (-) as word separators rather than underscores (_).

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow should be required, the maintainer team should be notified.

Bug fixes

• There should be at least one unit or end-to-end test.
• The Pull Request description should include a link to an issue that describes the bug.

Non-trivial changes

• There should be some code comments as to why things are implemented the way they are.

New/Existing features

• Should be documented, either by modifying the existing documentation or creating new documentation.
• New features should have a link to a feature request issue or an RFC that documents the use cases, corner cases and test cases.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• vtctl command output order should be stable and awk-able.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from VTop, if used there.

[rsajwani]

There are some failures .. you might need to fix them ..

[deepthi]

These changes LGTM. However, any fixes for the test failures will need a review, hence deferring approval until then.

[frouioui]

@deepthi @rsajwani, I have "fixed" the problem by reverting the changes made to two workflows which were unnecessary. However, I found a problem that is common to both the CI and arewefastyet: when building binaries with go1.19.* on release 14 and below, the compilation errors out with the following output:

Wed Nov 9 20:43:19 UTC 2022: Building source tree
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x57d886]

goroutine 1 [running]:
debug/elf.(*Section).ReadAt(0xc000280000?, {0xc0001c7b00?, 0x1c8?, 0x17?}, 0x40?)
	<autogenerated>:1 +0x26
archive/zip.readDirectoryEnd({0x6c28c8, 0xc0001dca80}, 0x210)
	/opt/hostedtoolcache/go/1.19.3/x64/src/archive/zip/reader.go:526 +0xf5
archive/zip.(*Reader).init(0xc00019b730, {0x6c28c8?, 0xc0001dca80}, 0x210)
	/opt/hostedtoolcache/go/1.19.3/x64/src/archive/zip/reader.go:97 +0x5c
archive/zip.NewReader({0x6c28c8, 0xc0001dca80}, 0x210)
	/opt/hostedtoolcache/go/1.19.3/x64/src/archive/zip/reader.go:90 +0x5e
github.com/daaku/go%2ezipexe.zipExeReaderElf({0x6c2d28?, 0xc000012580}, 0x547eff8)
	/home/runner/go/pkg/mod/github.com/daaku/go.zipexe@v1.0.0/zipexe.go:128 +0x8b
github.com/daaku/go%2ezipexe.NewReader({0x6c2d28, 0xc000012580}, 0x0?)
	/home/runner/go/pkg/mod/github.com/daaku/go.zipexe@v1.0.0/zipexe.go:48 +0x98
github.com/daaku/go%2ezipexe.OpenCloser({0xc00001f860?, 0x2c?})
	/home/runner/go/pkg/mod/github.com/daaku/go.zipexe@v1.0.0/zipexe.go:30 +0x57
github.com/daaku/go%2ezipexe.Open(...)
	/home/runner/go/pkg/mod/github.com/daaku/go.zipexe@v1.0.0/zipexe.go:[16](https://github.com/vitessio/vitess/actions/runs/3430762721/jobs/5719803860#step:11:17)
main.operationAppend({0xc000012570, 0x1, 0xd797735108?})
	/home/runner/go/pkg/mod/github.com/!geert!johan/go.rice@v1.0.0/rice/append.go:39 +0x4[18](https://github.com/vitessio/vitess/actions/runs/3430762721/jobs/5719803860#step:11:19)
main.main()
	/home/runner/go/pkg/mod/github.com/!geert!johan/go.rice@v1.0.0/rice/main.go:43 +0x1a5
exit status 2
make: *** [Makefile:66: build] Error 1

I haven't spent much time investigating the reason why. I'll add that to my list as it's currently blocking arewefastyet's benchmarks on release-14.0 and below. From what I have tested, local make build does not reproduce the issue (at least on OSX).