Feature flags: js, ~~rustix~~

[dhardy]

This adds two feature flags: "js" and "rustix". These both enable the corresponding backend and use it by default (still allowing override with getrandom_backend, except that wasm32 sans OS has no viable alternative).

Result: a minimal crate dependant on getrandom has its lockfile reduced from 33 to 16 entries. Going further than this would require disabling WASI and/or Windows targets by default (windows-targets in particular adds a lot of entries).

Compromise: a direct dependency on getrandom is needed to enable the required target. And since this also default-enables the target, it likely should only be added in the final binary, as with getrandom v0.2. I considered not default-enabling the backend (i.e. one needs to both use --features=js and getrandom_backend=wasm_js to use the backend) but this is likely confusing (besides being tedious).

I'm not sure whether this is actually a good idea, but I don't see a better alternative than simply choosing not to address the issue of a large lockfile brought up here.

[newpavlov]

As I wrote in the issue, I think it's better to introduce an opt-in feature which would allow users to enable optional backends using configuration flags. It would resolve the lock file bloat issue and would be universal for all opt-in backends.

[dhardy]

@newpavlov features must be additive, so we can't use an opt-in feature to remove functionality which would otherwise be available by default. And what do you mean by "configuration flags"? Isn't that what getrandom_backend already is, which is already causing lockfile bloat due to not trimming the dependency tree according to platform or configuration flags?

The only real alternatives I see here are (1) something similar to this PR but don't enable the backend by default (i.e. require using the feature flag and setting getrandom_backend to use wasm_js) or (2) the status quo (decide not to fix the bloat; maybe Cargo will eventually but I have my doubts since I wouldn't expect a configuration flag to affect Cargo.lock; in fact this is what @hanna-kruppe said in the other thread).

[dhardy]

Merge due to #573.