Employ AsEventSource and GetEventTypes core methods for routing

[tzununbekov]

These core functions can be used as a backup method to define filter conditions if the CRD is not providing enough information.

[jmcx]

Example:

tmctl create source cloudevents
tmctl create target http --source foo-cloudevents

=> events from foo-cloudevents will have the CE "source" attribute set to e.g. local.foo-cloudevents, and we could try to use that to help create the underlying trigger filter.

[tzununbekov]

Described methods are employed in the CLI's branch ce-source-routing and are about to be merged into the main.

This update does not resolve the issue with the CloudEvents source because although the source announces itself here as s.Namespace + "." + sourceName, this attribute is never used in actual events processing. I believe that the CloudEvents source intended behavior is not to change the original CE attributes (unless CE overrides explicitly defined), so the current processing logic is fine. What's confusing there now is the AsEventSource method that returns the misleading attribute value. IMO, if the component does not change the CE's source attribute, it could return either * or -, just like the GetEventTypes method. If we update source's AsEventSource method to return one of these, CLI will spit the error "CloudEventsSource" does not expose event source attribute, which I believe is the best option right now.
/cc @odacremolbap @jmcx

[jmcx]

sounds good 👍

[tzununbekov]

Related to #100.
As explained in #103, manual testing showed that the extra routing attribute (EventSource) in current user scenarios does not give any advantages over a single EventType routing configuration. On contrary, having event source for the component name and event source for the CE attribute is quite confusing. Having all that, the EventSource attribute was removed from the CLI routing, leaving EventType the only attribute associated with the event producers and exposed to users. We can bring it back later when we clearly define the problem that EventSource will solve for us.
Meanwhile, the error message for CloudEventsSource kind of scenarios was improved to better explain the reason:

2022/11/07 18:40:17 "foo-cloudeventssource" event source: "cloudeventssource" does not expose event type attributes

There is no solution suggested in this output, at the moment. We could put the link to the source documentation page there when we have it.

[jmcx]

Sounds good.

Later, when we start exposing a "filter" parameter in Triggers via the CLI, users will be able to manipulate those attributes if they want anyhow (if that makes sense)

e.g. tmctl create trigger filter=type=mytype,source=mysource,customextension=customvalue