_ci_ Appimage go1.18.1 fix

[ianconsolata]

Related Issues

The original PR (#9389) to address this issue didn't remove the old version of golang from the machine image first, which causes errors (https://app.circleci.com/pipelines/github/filecoin-project/lotus/23476/workflows/9956a546-066d-4d95-861e-7a50237a6762/jobs/609677)

Proposed Changes

This PR fixes that by removing the old version of go.

It also introduces a new GO_VERSION file that defines the target go version in a single place that external and internal build automation processes can use to determine which version of go should be used when building the project: #9494

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title is in the form of of <PR type>: <area>: <change being made>
  • example: fix: mempool: Introduce a cache for valid signatures
  • PR type: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, test
  • area, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[geoff-vball]

@ianconsolata Based on the conversation here, I think the file as-is will cause a bit of confusion. I suggest either renaming the file to GO_VERSION_MIN or moving it to the .circleci folder as-is. I think the former would be a little better as we could reuse the variable in a few of our other scripts.

[ianconsolata]

Why do we use the minimum supported version to build the project? Will that always be the case? Why not use the latest 1.18 version to build, instead of explicitly using the min version? (Happy to name it whatever, just trying to understand the scope of how the team treats go versions)

[geoff-vball]

@ianconsolata All I know is what @magik6k mentioned in slack the other day:

So far we've been sticking to
Minimum 1 minor version behind
So that users have good amount of time to update and new features have time to stabilize, or are discovered to be buggy in some way
Support latest as soon as it's out
Many people are using Arch Linux, including many devs, and Arch gets new Go releases very quickly

We could definitely use a version higher than our minimum to build. We have a bug right now stopping use from using 1.19.

[ianconsolata]

I just updated that issue (#9456), as I think the 1.19 issue is specific to lotus-fountain.

I'll make this GO_VERSION_MIN and integrate it into the Makefile check that errors if you use a version smaller than it.

[ianconsolata]

Ok, anywhere else this should be integrated into the build tooling?

[geoff-vball]

@ianconsolata Looks good to me!