feat: make it possible to filter message by origin

[octonato]

Draft since depending on https://github.com/lightbend/kalix-runtime/pull/3488

[octonato]

Some updates on this PR.

• consumer and views receive originRegion in context
• all components can have access to selfRegion via Context

Some other ideas that we can include here or in follow-up. We might want to add API to set the originRegion in the Eventing Testkit.

[octonato]

Context is ubiquitous. All contexts inherit from it. By adding the selfRegion here we make it possible to always check 'where' we are.

This includes component creation contexts, command contexts, http request context and consumer messages (both consumers and views).

[octonato]

MessageContext (Consumer) and UpdateContext (Views) now extends OriginAwareContext which gives access to the originRegion and method hasLocalOrigin.

[aludwiko]

I mentioned this on the runtime side, but maybe I should do it here. In my opinion, it feels more natural to get the originRegion information from the metadata. We can add a helper method extract it, similar to subject, time, etc., I guess there was a reason to make it this way, what was that?

[aludwiko]

hasLocalOrigin is nice, but if that is the only reason, I think users can create such a method themselves if they need it.

[aludwiko]

I think the implementation with meta will also be much simpler because we are passing this information through all the layers from the runtime to the sdk.

[octonato]

The reason why I didn't add it to the metadata is because we used to also have JWT and ACL there and we stepped away from it. JWT and ACL is now only present on the endpoints request, which makes more sense.

Also, metadata is available in places where it doesn't make sense to have the originRegion, for example in commands. We should have it only when consuming messages.

[octonato]

About hasLocalOrigin, the method impl is quite simple and indeed anyone can implement this logic, but there is some hidden knowledge in there that otherwise we will need to document.

1. empty means we are consuming from a broker or service-to-service, so not local
   (we will have to document this)
2. for non-empty origins, it needs to match selfRegion, so it depends
   (this is easy and kind of obvious)
3. in dev-mode, both will be "" and therefore local by definition
   (this is also hidden logic that this method is encapsulating)

[aludwiko]

Also, metadata is available in places where it doesn't make sense to have the originRegion, for example in commands. We should have it only when consuming messages.

Good point, but that implies that we have a leaking abstraction because I can run metadata.asCloudEvent in my command handler, which doesn't make any sense. Maybe we should have a separate CommandMetadata, Message/EventMetadata ?

[patriknw]

in docs we have a todo, related to this:

ifdef::todo[TODO: describe conditional processing https://github.com/lightbend/kalix-runtime/issues/3098 ]

[octonato]

in docs we have a todo, related to this:

ifdef::todo[TODO: describe conditional processing https://github.com/lightbend/kalix-runtime/issues/3098 ]

Sure, we will need to document this.