Improve golang upgrade process

Summary

I recent outage on gitlab.com gitlab-com/gl-infra/production#5521 (closed) was caused by a golang upgrade from 1.16.x to 1.17

As an result we want to improve the process we take for golang upgrades. The current process is documented here: https://docs.gitlab.com/ee/development/go_guide/index.html#updating-go-version

From feedback in gitlab-com/gl-infra/production#5533 (closed), we know we want the process to:

1. Add a step for opening and epic for the upgrade, to create a point of cross-team/project engagement and discussion
   • And example of this is the epic for the ruby 3.0 update: gitlab-org&5149 (closed)
2. Include a step that ensure the new version of golang has been used in the gitlab GDK prior to the CNG and Omnibus MRs
3. Include steps for announcing that the change is happening
   • Announce in internal channels after its available in the GDK, so developers can test
   • Announce again when the CNG and Omnibus MRs are merged
4. Describe the sort of testing that should occur prior to merge

Feature Change Lock

This issues is part of #925 (closed)