ARROW-10627: [Rust] Loosen cfg restrictions for wasm32

[nevi-me]

One of our recent changes made compiling under non-x86/amd64 platforms to return errors.
This removes those restrictions as a quick fix.

I'm a bit wary of introducing wasm32 targets into CI for now, as the tests don't yet work, and we would just increase CI time for everyone.
There is also a separate JIRA for this work, so I'm not including it here.

[github-actions]

https://issues.apache.org/jira/browse/ARROW-10267

[jorgecarleitao]

LGTM.

We could place it as a cron job. The issue is that those do not report anywhere AFAIK :(

[nevi-me]

The issue is that those do not report anywhere AFAIK :(

I thought of that, but the lack of reporting other than an ignoreable e-mail is a deterrent.
There's a stale PR trying to implement wasm32 support. I intend on picking it up at some point, so I'm delegating the CI work to it.

[jorgecarleitao]

IMO we should refactor the CI: each compilation should be a different job with a diffetent cache so that everything can be done in parallel.

[nevi-me]

Different job per crate, or per target? (stable, various features with nightly, non-x86 targets)

[github-actions]

https://issues.apache.org/jira/browse/ARROW-10627

[jorgecarleitao]

(this is not for now and not blocking this PR, it is just a thought)

Not necessarily per target or crate:

As I see it, we have builds that we do sequentially on the script.sh, but that do not benefit from being built in sequence. Even when they do not benefit, I think that we would benefit from splitting them in multiple jobs and use artifacts to share the common state (target in this case) between them, so that caching is more granular.

More generally, our builds are basically a DAG where each node is an execution that benefits from having artifacts available:

• build arrow ext dependencies libs: []
• build arrow lib: [arrow ext dependencies libs]
• build parquet lib: [parquet ext dependencies libs, arrow lib]
• build arrow tests bin: [arrow tests ext dependencies, arrow lib]
• build parquet tests bin: [arrow tests ext dependencies, arrow lib, parquet]
• run tests: [arrow tests bin]

A feature flag is a new build of the lib+bin, but typically shares the same external dependencies and thus would be something like

• build arrow lib simd: [arrow ext dependencies libs]
• build arrow tests bin: [arrow tests ext dependencies, arrow lib simd]
• run tests simd: [arrow tests bin]

Each tuple (architecture, compiler, compiler flags) does not share lineage with other tuples and can run in parallel.

Currently we run our DAG in sequence. However, there are many nodes on this DAG that do not depend on each other and can run in parallel (different jobs in github flow).

IMO if we split our build in different jobs that outputs an artifact and create a DAG of these jobs, we are able to run our pipeline faster by leveraging parallelism of the build.

This is something that I fielded on the mailing list in the context of the integration tests, but that it is also applicable to our own builds.

[nevi-me]

I don't have much experience with Github Actions, but I know that Gitlab CI allows one to express that DAG structure very well; so I understand what you mean.