routingprocessor: remove broken debug log fields

[pmalek-sumo]

Description: Remove broken debug log fields in routingprocessor

The logger fields that were added as part of the last change introduced the following unwanted log output:

2021-11-18T14:51:59.175Z    debug    routingprocessor@v0.38.0/router.go:400    Registering exporters for routes    {"kind": "processor", "name": "routing", "exportersError": "json: unsupported type: componenthelper.StartFunc"}
2021-11-18T14:51:59.175Z    debug    routingprocessor@v0.38.0/router.go:446    Registering exporter for route    {"kind": "processor", "name": "routing", "route": "/prometheus.metrics.apiserver", "availableError": "json: unsupported type: componenthelper.StartFunc", "requested": ["sumologic/apiserver"]}
2021-11-18T14:51:59.175Z    debug    routingprocessor@v0.38.0/router.go:446    Registering exporter for route    {"kind": "processor", "name": "routing", "route": "/prometheus.metrics.container", "availableError": "json: unsupported type: componenthelper.StartFunc", "requested": ["sumologic/kubelet"]}

So let's remote them.

[jpkrohling]

Can we get a list of exporter names out of this map, instead of just removing it?

[pmalek-sumo]

We could but I'd need to iterate over the whole map and save it in a slice (conditionally on a log level? Can this be easily done?). Would that be ok?

[jpkrohling]

Not sure it's worth it -- it would certainly be helpful to know the available exporters and the requested for the route, but perhaps the extra code wouldn't be worth it...

[jpkrohling]

I'm approving, but feel free to send an update to this PR if you can find a cheap and reasonable way to list the exporters. If you are OK with merging as is, let me know.

[pmalek-sumo]

I'm approving, but feel free to send an update to this PR if you can find a cheap and reasonable way to list the exporters. If you are OK with merging as is, let me know.

Let's leave it as is for now. As far as the "cheap and reasonable way": this is just happening on the registration when processor initializes itself so we shouldn't be that concerned about it being cheap/not cheap :)