multi: Use atomic types in exported modules.

[jholdstock]

go 1.19 introduced new atomic types which hide the underlying primitive types so that all accesses are forced to use the atomic APIs. This makes the code less prone to human error and a bit less verbose.

Extracted from #3053 which was originally a repo-wide change, this PR includes just the exported modules.

[davecgh]

Copying the relevant discussion from #3053:

From @davecgh:

...

Note that this change would have to bump the relevant go.mod files to require Go 1.19 because the types were not introduced until Go 1.19.

... I'd prefer not to needlessly require newer Go versions for the other modules which hoist everyone else forward (at elast yet) unless there is a really good reason and I don't think this qualifies.

From @jrick:

Go <=1.18 no longer receives security patches. I'm fine leaving it behind.

From @davecgh:

That's a choice each consumer has to make with their own projects, imo. I don't think it's fair to force our own policies on everyone who uses our modules just to get updated versions of them in general. As someone who has been bitten many times by being on the receiving end of such policies, I'm particularly sensitive to it.

For any cases where there is a legitimate security issue resolved that genuinely requires a new version, we'd obviously bump them.

It might also be reasonable to follow the Go bootstrap toolchain as a minimum here since you won't even be able to build the relevant version of Go without that version.

[jrick]

It might also be reasonable to follow the Go bootstrap toolchain as a minimum here since you won't even be able to build the relevant version of Go without that version.

The bootstrap is only intended for building a more recent Go. There is no reason to build any other project from it.

[jholdstock]

Rebased after #3055

[jholdstock]

Rebased and updated for 2024

[teknico]

The CI pipeline is only using Go 1.21 and 1.22, so building on 1.19 and 1.20 is promised but not checked.

Adding these two older versions to the CI would double the time it takes to run the tests on each PR update.

And even then, building the non-main modules on 1.17 and 1.18 would still not be checked.

[jholdstock]

Rebased and updated for 2025

[davecgh]

If you want to split off the addrmgr changes to a separate PR, I think we can go ahead and get those merged. I say that because we just released a new v3 module and so nobody will be using it on super old Go version unlike what is potentially the case for others.

[jholdstock]

Done in #3577