Make CIRCL runs on non-amd64 architectures.

[armfazh]

Motivation: The principal offender why CIRCL breaks on s390x was due to endianness ordering.
Changes:

• remove unsafe pointer conversion (as in C) since it breaks on arch with bigEndian ordering.
• Updates CI, so it tests on arm64, amd64 and s390x.
• Some packages do have non-arch specific implementations, but it wasn't compiling well. Now, it's fixed.
• golangci-lint uses a github action.
• s390x emulator breaks when multiple goroutines listen for signals. Setting GODEBUG='asyncpreemptoff=1' removes this restriction.

[claucece]

Awesome! I'll check this tomorrow. I was checking out possibilities for not using vendor. What do you think of this proposal: golang/go#32966 ?

We can also add a 32 architecture machine, now that we are it, as 'qemu-user-static' also supports arm32v6 and arm32v7...

[armfazh]

Awesome! I'll check this tomorrow. I was checking out possibilities for not using vendor.

This PR does not requires to vendor anything.

What do you think of this proposal: golang/go#32966 ?

There might be cases for which this could be helpful.

We can also add a 32 architecture machine, now that we are it, as 'qemu-user-static' also supports arm32v6 and arm32v7...

Yes, that can be included in a different workflow triggered with a special tag. I want the current workflow runs fast.

[claucece]

This PR does not requires to vendor anything.

I was referring to go test -mod=vendor.

Yes, that can be included in a different workflow triggered with a special tag. I want the current workflow runs fast.

Sure. Looking at the docs, seems like using if will help: https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif

[wbl]

Should we think about which architectures we want to test support for?

[armfazh]

Should we think about which architectures we want to test support for?

Most of the current code targets AMD64 architecture, and most of the algorithms provide generic implementations relying on stdlib, ( and this is one way to support other architectures).

Testing on s390x allowed us to discover errors on our generic implementations without giving explicit support to s390x.

So, I think testing on other architectures is good. The only downside is that CI takes longer to execute.

[bwesterb]

Should we think about which architectures we want to test support for?

Definitely ARM64.