Verify datadog_metrics sink

[neuronull]

• Verify internal event processing metrics are tested via assert_X_compliance test helpers
• Update component_discarded_events_total to match the new instrumentation spec by adding reason to the emitted logs, and intentional to emitted logs and metrics
• Verify that the component correctly emits the correct error events per the component spec

[neuronull]

Added compliance test helper

[neuronull]

For adhering to spec, evaluated (may reach into other files):

• sink.rs
• config.rs
• encoder.rs
• service.rs
• normalizer.rs
• request_builder.rs

[neuronull]

Should we fire internal events for errors while building the DatadogMetricsRequestBuilder, or basically anything in the sink build path that is utilizing ? to cascade up errors.

[neuronull]

I'm contemplating if we should be emitting internal events at these sink infrastructure common code locations, , or if we should be catching the errors downstream of that and emitting there.
(1) :

vector/lib/vector-core/src/stream/driver.rs

Lines 122 to 125 in 7b877d6

	Poll::Ready(Err(err)) => {
	error!(message = "Service return error from `poll_ready()`.", ?err);
	return Err(())
	}

(2):

vector/lib/vector-core/src/stream/driver.rs

Lines 170 to 173 in 7b877d6

	Err(error) => {
	error!(message = "Service call failed.", ?error, request_id);
	finalizers.update_status(EventStatus::Rejected);
	}

[neuronull]

Should we fire internal events for errors while building the DatadogMetricsRequestBuilder, or basically anything in the sink build path that is utilizing ? to cascade up errors.

Looks like that is handled in run_inner(), using the RequestBuilderError.