Improved build staging and control

[workingjubilee]

While #27 is no longer on the table, in order to make #70 happen, and to make #26 easy, PL/Rust needs builds that are slightly more finely staged and offer more user input, so the user can easily recover things like the Cargo.toml and Cargo.lock that PL/Rust is going to use. In addition, we would like to run the build under various debug or other settings of their choice. Currently, we hardcode all build settings to run once the crate is provisioned:

plrust/src/user_crate/state_provisioned.rs

Lines 49 to 61 in 37c2c49

	command.current_dir(&self.crate_dir);
	command.arg("rustc");
	command.arg("--release");
	command.arg("--target");
	command.arg(target_str);
	command.env("PGX_PG_CONFIG_PATH", pg_config);
	if let Some(target_dir) = target_dir {
	command.env("CARGO_TARGET_DIR", &target_dir);
	}
	command.env(
	"RUSTFLAGS",
	"-Ctarget-cpu=native -Clink-args=-Wl,-undefined,dynamic_lookup",
	);

For correctness purposes, it is important that after crate generation and before the build that PL/Rust guarantees that "nothing happens" from the perspective of actually running the build. However, this is also probably the perfect time for events which examine the crate without actually fully building and running it.

We want to be careful about exposing control over the build options that are input, as compiler options are implicitly "unsafe". Thus, unlimited access to the compiler's command flags may allow instructing the compiler to run the build under parameters that can hypothetically violate any safety properties we have embedded in the PL/Rust design.

• Add staging for pre-build events: Catch #[no_mangle] #128
• Support "no-op" validation: Diet of WORMs #143
• Question: Must this apply to build artifacts as well?
• Improve UI for manually recovering build deets from inside the PL/Rust builder
• Add UI for running user-provided introspection during provisioning
• Add more UI for controlling the build itself
• Consider UI for incremental introspection during crate building (for builds that may involve complex build.rs steps)

[workingjubilee]

Hm. UI design is not trivially obvious here.

Major consideration: It may seem like this is a "validation" step and so it wants to be part of the "validator function", but is that the best idea? That predetermines the validator function call point: before the build is actually run. And the validator also is always called with no arguments, which makes it annoying to configure what the validator actually does in terms of checks aside from already-supplied methods. We want to have this as an option for catching a nefarious build.rs that might be executed, and we want to have an unambiguous path to doing so.

[workingjubilee]

Preferred UI design remains unclear but this got partially unblocked on the code level by the introduction of a specially-reserved "validation" stage in #128. A requirement that was revealed by that initial implementation is that this should not actually need to write the lib.rs to the filesystem twice for the built/audited source code, and that was satisfied in #143.