Honor rust-toolchain.toml file in xtask, remove env vars with CARGO/RUST prefix

[arctic-alpaca]

Command::new creates a child process which inherits all env variables. This means env vars set by the cargo xtask command are also inherited. This leads to the rust-toolchain.toml file in the -ebpf folder not being honored. To fix this, all env vars starting with CARGO or RUST are removed before the child process is created.

This approach also means the run/build-ebpf tasks cannot be influenced by env vars set when using cargo xtask run/build-ebpf. I think this is a lesser issue than hardcoding nightly or the approach in #69.

[alessandrod]

Why are we removing all variables? It seems to me we should only remove RUST_TOOLCHAIN as it will clobber rust-toolchain.toml.

We shouldn't make assumptions about the rest and it's not our business to remove them. The child cargo invocation will override the CARGO_* ones. The rest could have been set by the user and we should leave it there.

[arctic-alpaca]

I compared what was set in the cargo xtask process to what was set without any cargo invocation. Without any cargo invoration, no CARGO... or RUST... env var was set on my system. If we keep CARGO... env vars, some config from the xtask invocation leaks into the build-ebpf invocation.

You can check what get's set by printing env vars just before the cargo command is started.

[alessandrod]

I compared what was set in the cargo xtask process to what was set without any cargo invocation. Without any cargo invoration, no CARGO... or RUST... env var was set on my system. If we keep CARGO... env vars, some config from the xtask invocation leaks into the build-ebpf invocation.

No, because the child cargo invocation will override those. This is a documented cargo interface https://doc.rust-lang.org/cargo/reference/environment-variables.html

[arctic-alpaca]

I wasn't aware of that, I'll change the PR to only remove RUSTUP_TOOLCHAIN tomorrow (EU time).

[arctic-alpaca]

Is there anything left that needs to be addressed in this PR?

[vadorovsky]

@arctic-alpaca Yes, CI failures. ;)

Could you pin nightly to 2023-01-10 here?