Handling environment variables for local and remote builds about buck2

[JakobDegen]

So buck2 mostly does this right. When defining actions, rules can specify some environment variables to set, and buck2 will use this information to decide when to rerun or not rerun an action. Rules can in turn expose this interface to users via an attribute, for example the env attribute in rust_library. This isn't available on all rules, but normally not too hard to add

That being said, in addition to the "tracked" environment that is actually expressed in the build graph, actions also inherit what you might consider a default environment. This part of the environment is not tracked by buck2 and will not result in rebuilds if changed.

When using remote execution, the default environment is fully determined by the backing RE implementation, so you'll have to consult their documentation for what that default environment looks like. #532 was an example of breakage caused by different RE implementations making different decisions here. The local environment on a users machine should never have any effect on the build in this case.

Local execution, on the other hand, is currently un-isolated in buck2. Specifically, the environment that local actions inherit will be the same one that was used to start the daemon. Just like how buck2 does not enforce that you declare all your inputs, it also does not enforce that you don't depend on untracked parts of the environment. The Rust rules try and protect against this by explicitly sanitizing the environment before invoking rustc - that behavior is what #466 is about.

Sanitizing the local environment would be an important part of an implementation of isolated local actions.