[routingconnector] convert routing processor to a connector

[mwear]

Description:

This PR introduces a connector version of the routing processor. It currently supports routing based on resource attributes OTTL statements only. Context based routing will be added later in a followup PR.

There are two issues regarding fanout consumers that are being addressed in the core repo.

• The routing connector needs to be a consumer in multiple pipelines (the routing processor can route to a single exporter).
  • Will be resolved by: Always pass fanout consumers to connector factory functions opentelemetry-collector#7840
• We need the ability to create connector routers to facilitate testing. I had to temporarily copy the fanoutconsumer package into the routing connector codebase due to package visibility issues.
  • Will be resolved by: Add helpers to construct connector.*Routers for tests opentelemetry-collector#7673

We can address these issues as the relevant PRs land on the core repo.

cc: @djaglowski, @jpkrohling, @kovrus

Link to tracking Issue:
#19738

Testing:
Unit / manual

Documentation:
The readme has been ported from the routing processor

[djaglowski]

@mwear, thanks for taking this on. I'm excited to see so much progress.

[mwear]

@djaglowski thanks for the initial round of feedback. I was wondering if you had any opinions on the two issues I ran into with the fanoutconsumer (mentioned in the description). I could work around the package visibility issue by introducing mock fanout consumers for the tests, but the actual fanout consumer is subtly complex, which introduces some risk. I have worked around the second issue, needing a connector be a receiver in multiple pipelines in order to get a fanout consumer, by adding that restriction to the routing connector; the processor did not have this restriction. Is that the right thing to do, or can we add the cabability to request a fanout consumer for a connector even if it is only a receiver in a single pipeline, the advantage being, that we can still request a consumer by name.

Let me know if you have opinions on those issues. I was waiting to get some resolution on them before taking this out of draft.

[djaglowski]

@mwear, regarding problem 1 noted above:

I see what you are saying. I think what it boils down to is that we need a way for tests to create a connector.TracesRouter (and same for metrics/logs of course).

If we move fanoutconsumer from service/internal to internal, then connectortest could provide a minimal surface area to produce a "real" router that is only sufficient for testing. Something like the following - WDYT?

type tracesRouterTestOption struct {
	id component.ID
	cons consumer.Traces
}

func WithNop(id component.ID) tracesRouterTestOption {
	return tracesRouterTestOption{ id: id, cons: consumertest.NewNop() }
}

func WithTracesSink(id component.ID) tracesRouterTestOption {
	return tracesRouterTestOption{ id: id, cons: &consumertest.TracesSink{} }	
}

func NewTracesRouterSink(opts ...tracesRouterTestOption) connector.TracesRouter {
	consumers := make(map[component.ID]consumer.Traces, numRoutes)
	for _, opt := range opts {
		consumers[opt.id] = opt.cons
	}
	return fanoutconsumer.NewTracesRouter(consumers)
}

[djaglowski]

Regarding problem 2:

I tend to think that a router really should expect a minimum of two downstream pipelines. It seems that anything that could be done with a router that emits to only one pipeline, could (and should) be done in a simpler way.

[mwear]

@djaglowski: Thanks for the suggestions. I like your proposal for problem 1 and will work on a PR for it. I'm fine with leaving problem 2 as is. It makes sense to require multiple downstream pipelines, even though it introduces a slight difference in behavior for the connector vs the processor.

[mwear]

I'll leave this in draft until there is some resolution on: open-telemetry/opentelemetry-collector#7673. I'll also be OOO next week (back on May 22nd). I welcome any feedback in the meantime, and will address it when I return.

[kovrus]

It seems that quite some users (including me) do routing based on the context values. Maybe after this PR we can follow up with the OTTL function that extracts values from context if it is possible.

[mwear]

We can add context based routing as a follow up, but we should discuss how we'd like that to work so that we don't paint ourselves into a corner with the first pass.

[jpkrohling]

I'm way behind my github notifications, but I'm placing this to the top of my queue.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[djaglowski]

This PR is waiting for @bogdandrutu's response here: #21498 (comment)

[djaglowski]

@mwear, I think we should move forward with the temporarily copied fanout consumer code. WDYT?

[mwear]

@mwear, I think we should move forward with the temporarily copied fanout consumer code. WDYT?

That works for me. Removing the copied code will be easy once the other changes land on core. Should I dust this off and bring it out of draft?

[djaglowski]

@mwear, I'm all for it. 👍

[djaglowski]

A few comments have not been marked as resolved, but I believe all concerns have been addressed. @jpkrohling, @kovrus, please double check the open comments and raise issues if you would like to see additional changes.

@mwear, thank you for all the work on this! This is a critical connector and I'm looking forward to making it available to users.