chore: upgrade to 1.21

[lzap]

Bump to Go Toolbox 1.21.6 from RHEL 9.4.

[lzap]

Omg I knew this is gonna hit us some day. And it hits hard. Go 1.21 updated how init() functions are called. Unfortunately, we heavily rely on init functions for stub clients, job queue and other stuff instead calling explicit initializers. It is more convenient for ability to run tests individually. However, ordering is a mess:

$ GODEBUG=inittrace=1 make test 2>&1| grep init | grep provisioning

Unfortunately, go test does not work well with inittrace. It can be exported but then it is a mess.

[ezr-ondrej]

I need to figure out how to solve this.

Good topic for a tech discussion I'd say :)

[lzap]

I have half of the patch done, will finish it on Monday. I got rid of all init functions, but it is quite big one.

[lzap]

So I was working for two days on complete refactoring of init trying to make it explicit, but I ran into way too many import cycle problems that manifested only after side effect importing was done for some reason. I am falling back now to figure out a different way out.

[lzap]

There are couple of changes like this, I did not pay attention and IDE fixed these for me. These are not relevant, will not hurt I guess.

[ezr-ondrej]

I like it, that's the way C++ headed last time I lookes as well, no useless explicity :)

[lzap]

So the solution was rather simple, but I spent quite some time trying to do a big-bang refactoring, I ran into many import cycle problems and it was a dead end.

The solution I am proposing is to move all GetXXX function init() initializers into files named 0init.go and include or exclude them depending on if unit tests are executed. Because it is not possible to guarantee the order of when package is being imported it sometimes loaded stubs and then overwritten the GetXXX function with real implementation later on. I tried to only set once, but that did not do the trick so the final solution is to actually avoid this init() code alltogether. When running real code (no build tags) or integration tests then only the relevant init() function will be called.

Lessons learned:

* Never ever use init() this way anymore, it is fine for local initialization but this is a pain to debug or work with.

• Think more about inter-package dependencies to avoid import cycles. Specifically the design when we have a common package with many common code and types (e.g. dao) and then packages which use that (e.g. dao/pxy and dao/stub) are prone to import cycles.

[lzap]

/retest

[adarshdubey-star]

/retest

[adarshdubey-star]

/retest

[ezr-ondrej]

Cool! lets do it! 🎉