explain: remove Filter layer from OptimizerTrace stack

[aalexandrov]

It's not clear why we need this, and it might be causing a regression in our optimization times.

This might be a root cause of MaterializeInc/database-issues#7881.

Motivation

• This PR fixes a recognized bug.

Fixes MaterializeInc/database-issues#7881.

Tips for reviewer

I don't think we need the extra

.with(tracing::level_filters::LevelFilter::TRACE)

layer in OptimizerTrace::new(...) because the Filter implementation for PlanTrace will always report interest in target: "optimizer" spans:

materialize/src/repr/src/explain/tracing.rs

Lines 214 to 230 in aff40a7

	impl<S, T> layer::Filter<S> for PlanTrace<T>
	where
	S: subscriber::Subscriber,
	T: 'static + Clone,
	{
	fn enabled(&self, meta: &Metadata<'_>, _cx: &layer::Context<'_, S>) -> bool {
	self.is_enabled(meta)
	}
	fn callsite_enabled(&self, meta: &'static Metadata<'static>) -> Interest {
	if self.is_enabled(meta) {
	Interest::always()
	} else {
	Interest::never()
	}
	}
	}

materialize/src/repr/src/explain/tracing.rs

Lines 245 to 249 in aff40a7

	/// Check if a subscriber layer of this kind will be interested in tracing
	/// spans and events with the given metadata.
	fn is_enabled(&self, meta: &Metadata<'_>) -> bool {
	meta.is_span() && meta.target() == "optimizer"
	}

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• This PR includes the following user-facing behavior changes: