chore : CoreTypes : Remove stray C dependency

[ribasushi]

Without this change the following test fails:

CGO_ENABLED=0 go test -count=1 ./chain/types_test.go

Without this fix importing the chain types into a fully-static executable is not possible.

I am not adding a test, as that should be done within the CI harness somehow (there is no way to force-disable compile-time flags from a test itself). Someone more familiar with how tests are run on a macro-level (@rvagg ?) should add a one-liner somewhere so things do not regress in the future.

[ribasushi]

Failure is a flaky itest (10m timeout). The new repo perms do not allow externals to assign revewers, so: @ZenGround0 @Stebalien @rvagg

[rvagg]

🤷 I don't have any bright ideas for locking in testing that would prevent regressions, we have unit tests all over the place that need cgo so it can't just be a re-run with a blanket exclusion, it'd have to be specific.

[rvagg]

@ribasushi how about removing the dependency completely so it'll be obvious if it ever comes back?

build/builtin_actors_gen_test.go still has a reference, which seems a bit redundant since we're now using 2 libraries for the same code paths .. perhaps it helps test correctness but do we think there's a problem?

cmd/lotus/daemon.go of course is the big one, it'd be interesting to get an idea of the speed difference importing a snapshot between the two implementations, if it's nearly as good, or better, then we may as well ditch the dependency entirely?

[ribasushi]

I don't have any bright ideas for locking in testing that would prevent regressions ... it can't just be a re-run with a blanket exclusion

@rvagg I meant a sub-runner for CI that re-executes just a portion of tests which specificaly deal with types. Not unlike the make unittests thing you made. As a start it could be as simple as what I wrote above: a list with a single entry chain/types_test.go. What I don't know is how everything is wired with CircleCI (or is it GHA now?).

[Stebalien]

@rvagg unfortunately, badger v2 pulls in github.com/DataDog/zstd. So we're not going to be able to completely ditch it. But:

1. I'd definitely remove it from builtin_actors_gen_test.go.
2. I'd leave it in cmd/lotus/daemon.go unless someone wants to benchmark snapshot imports (snapshot importing may be io bound, but I'm not sure).

[rvagg]

@ribasushi would you mind at least removing the test dependency?

[ribasushi]

@rvagg @Stebalien removed zstd from test. Though note that this is not about zstd itself at all.

If one wants to do anything at all with the chain, there are some types that can't be avoided ( TipSetKey, TipSet, etc ). All these "chain types" live in lotus, not in go-state-types.

Infecting this part of the codebase with any CGO dep is what the issue is. This is why I keep asking for advice how to ensure that the type tests run under CI with and without CGO

[rvagg]

We could build this into the test.yml workflow - add another utests item with a specific list and add a new property like yugabytedb and parameters to inject the cgo disable env var. But ./chain/types_test.go doesn't buy you much, just Message and SignedMessage, right?

If you want to make a list of tests to run I can try and work on something but there's just not much to ./chain/types_test.go that it doesn't seem worth the hassle to me.