Reorganize `Process` to include extra global states

[rami3l]

This was part of the original plan after #3803, but we probably have put it aside for a while:

In #4182 (comment), I've noticed that the current Process abstraction should probably be extended to allow the existence of a tracing_subscriber global state, so that we can handle graceful shutdown more easily.

Having noticed the clear pattern here:

rustup/src/bin/rustup-init.rs

Lines 44 to 53 in 52e6070

	#[cfg(feature = "otel")]
	opentelemetry::global::set_text_map_propagator(
	opentelemetry_sdk::propagation::TraceContextPropagator::new(),
	);
	let (subscriber, console_filter) = rustup::cli::log::tracing_subscriber(&process);
	tracing::subscriber::set_global_default(subscriber)?;
	let result = run_rustup(&process, console_filter).await;
	// We're tracing, so block until all spans are exported.
	#[cfg(feature = "otel")]
	opentelemetry::global::shutdown_tracer_provider();

... it should probably be modeled as an RAII guard.

I have also noticed that this should resolve another problem, i.e. the corresponding construct in tests is simply no longer used, as these two functions no longer have a caller:

rustup/src/test.rs

Lines 235 to 250 in 52e6070

	pub async fn before_test_async() {
	#[cfg(feature = "otel")]
	{
	opentelemetry::global::set_text_map_propagator(
	opentelemetry_sdk::propagation::TraceContextPropagator::new(),
	);
	}
	}
	pub async fn after_test_async() {
	#[cfg(feature = "otel")]
	{
	// We're tracing, so block until all spans are exported.
	opentelemetry::global::shutdown_tracer_provider();
	}
	}

This is most probably caused by the removal of rustup_macros (d60f005): indeed, the tests are passing on the CI, but sometimes one might want to run tests with otel on as well.

@djc What do you think?

[djc]

Right, I remember we discussed with @rbtcollins whether there was value in the OpenTelemetry support and he argued that it was very helpful for him the few times he needed it. I'm basically still not sure there is much value in the OpenTelemetry support that we've got and apparently may have broken it inadvertently.

I feel like, unless it's used regularly -- and it hasn't been for a few years at this point I guess -- it may be better to remove the feature altogether because it definitely has maintenance costs. Can always add it back when we need it, and I'm not sure fixing it now when we don't is a good way to use our time.

[rami3l]

Right, I remember we discussed with @rbtcollins whether there was value in the OpenTelemetry support and he argued that it was very helpful for him the few times he needed it. I'm basically still not sure there is much value in the OpenTelemetry support that we've got and apparently may have broken it inadvertently.

I feel like, unless it's used regularly -- and it hasn't been for a few years at this point I guess -- it may be better to remove the feature altogether because it definitely has maintenance costs. Can always add it back when we need it, and I'm not sure fixing it now when we don't is a good way to use our time.

@djc My mind hasn't changed too much since that discussion: I think we should at least have a way to obtain the timeline view lest some perf-critical regression happens (esp. regarding the diskio module). I don't particularly care what form that timeline view will be implemented, but reading the console traces just... feels wrong in this particular case. OTOH otel does look a bit heavy (we are paying too much for keeping it updated); macOS' Instruments looks good but is not platform-agnostic.

Again I'm looking at something like tokio-rs/console#129, but before that is implemented, maybe we can use another well-known backend such as the Chromium Tracing Tab that's more stable than otel (https://github.com/thoren-d/tracing-chrome).