chore(test): run go interop tests in the same rust process

[hanabi1224]

Summary of changes

This PR uses rust2go to invoke the go-kad test app in the rust process, to demonstrate how FFI for the f3 sidecar works.

Note that go1.21.x is required to run forest-interop-test

Changes introduced in this pull request:

• Move go-kad compact test to forest-interop-test and invoke with rust2go
• Move go-bitswap compact test to forest-interop-test and invoke with rust2go
• Update CI workflow and Makefile accordingly

Test result on CI: https://github.com/ChainSafe/forest/actions/runs/10355850383/job/28664406918?pr=4636#step:6:2191

        PASS [   1.077s] forest-interop-tests tests::bitswap_go_compat::bitswap_go_compat_test
        PASS [   2.859s] forest-filecoin::lint lint
        PASS [   1.131s] forest-interop-tests tests::kad_go_compat::kad_go_compat_test

Reference issue to close (if applicable)

Closes

Other information and links

Change checklist

• I have performed a self-review of my own code,
• I have made corresponding changes to the documentation,
• I have added tests that prove my fix is effective or that my feature works (if possible),
• I have made sure the CHANGELOG is up-to-date. All user-facing changes should be reflected in this document.

[hanabi1224]

This is required due to a bug ihciah/rust2go#10

[LesnyRumcajs]

The end binary doesn't require go, right? That is to say, if we ship the forest binary, there are no extra requirements (except the ones that are already listed in the Dockerfile)?

[LesnyRumcajs]

Should the generated file be included in the version control?

[hanabi1224]

I'm neutral about it. It's not required but makes code readable for users who solely browse the repo. What's your recommendation?

[LesnyRumcajs]

Pros:

• any change to it must be reviewed,
• somehow searchable.

Cons:

• will the changes to this file be actually reviewed or just blindly approved, especially when it'll be some obscure Go with C code?
• it introduces some noise, e.g., simple Cargo.toml or lockfiles are easily approved,
• while it allows some searching, it will also make general grepping more difficult - in my workflow, I'd need to disable looking in .go files to avoid noise.

All in all, if it's trivial to generate, I'd generate it on the fly and not add it to the version control.

[hanabi1224]

Removed

[hanabi1224]

The end binary doesn't require go, right? That is to say, if we ship the forest binary, there are no extra requirements (except the ones that are already listed in the Dockerfile)?

@LesnyRumcajs Yes, no extra dependencies(unless go-f3 dynamically links to other libs). BTW, this change happens to a publish=false test crate. We only need rust2go in forest when shipping f3 feature

[ihciah]

Hi! I'm the author of rust2go. Thank you for choosing rustgo! In out production environment we have validated its relibility.

One thing to note is that, remember to add GODEBUG=invalidptr=0,cgocheck=0 env when run it, otherwise there maybe panic invalid pointer found on stack in go side when it tries to grow the goroutine stack(related code). This env can also be added with golang code on init: os.Setenv("GODEBUG", ...).

For testing, it doesn't matter whether there is this environment variable or not. But if you use it to serve requests, remember to add it.

[hanabi1224]

Hi! I'm the author of rust2go. Thank you for choosing rustgo! In out production environment we have validated its relibility.

One thing to note is that, remember to add GODEBUG=invalidptr=0,cgocheck=0 env when run it, otherwise there maybe panic invalid pointer found on stack in go side when it tries to grow the goroutine stack(related code). This env can also be added with golang code on init: os.Setenv("GODEBUG", ...).

For testing, it doesn't matter whether there is this environment variable or not. But if you use it to serve requests, remember to add it.

@ihciah Thank you for the hints, this has been addressed in #4682