[Breaking] Fix issue where we have duplicate packages in tests

[Tatskaari]

When we build tests that aren't external, we have two versions for the package under test:

1. the package from the go_library() target that we're trying to test
2. the _{name}#lib package that re-compiles that package with all the test sources

Before we would have two different import paths for these two versions of the package. They're both available in the test binary, where the test version of the package is available as import "{name}_test_lib".

This causes a bunch of problems and confusion:

1. The package initialisation might happen twice which has causes issues registering various things that are meant to be unique
2. Components that are compiled against the production package expect the production types, which are not compatible with the test version

There are a few cases internally where a non-exported test imports the non-test version of the package to avoid type conflicts between the two versions of the packages.

This PR links the test version of the package into the binary, with the same import path as the prod version. This means there's no distinction.

TODO gate this behind a feature flag.

[peterebden]

Why is this breaking? Is it just because it stops this behaviour of registering things twice?

[Tatskaari]

Why is this breaking? Is it just because it stops this behaviour of registering things twice?

Yeah, there are a number of places in core3 where a test package imports itself. This is fine right now because the test vs. prod packages are different. Going forward this will be a cyclic import.

[peterebden]

Why is this breaking? Is it just because it stops this behaviour of registering things twice?

Yeah, there are a number of places in core3 where a test package imports itself. This is fine right now because the test vs. prod packages are different. Going forward this will be a cyclic import.

Right, thanks.

I think those are degenerate and they shouldn't have been doing that (albeit it was allowed and so eventually someone will try to do that thing). I don't think that would have worked with go build.