Add option to configure pre-defined "extraFields" to be added to each emitted thingEvent

[thjaeckle]

With the Ditto Signal Enrichment it is possible to dynamically configure for a single subscriber of "Thing Events" (whenever a Thing is modified) to get additional fields, which were not part of the change.
For example, all attributes or a special attribute which is required for the event consumer to have a context.

This works and is great.
However, this is also quite "costly" for Ditto - as the Gateway (for SSE and WebSocket) or Connectivity service of Ditto has to do another "internal" round-trip to fetch those extraFields. There are optimizations in place in order to cache them in a "smart cache" (which updates itself, etc.), but in the worst case, e.g. if the cache is full, this means a lot of roundtrips and networking.

There are scenarios when specific fields are always needed - that's why I suggest to configure (in the things service configuration) pre-defined extraFields which are pro-actively always sent in a DittoHeader field.
When the Connection or WebSocket "demands" this extraField (and e.g. no other), it can just use it from this header without additional roundtrips.
This should be configurable on a namespace level.

Example configuration:

pre-defined-extra-fields = [
  {
    namespaces = [
      "*"
    ]
    condition = "exists(definition)" # could be an option to also support a RQL condition here
    extra-fields = [
      "definition"
    ]
  },
  {
    namespaces = [
      "org.eclipse.ditto.lamps"
    ]
    extra-fields = [
      "attributes/manufacturer",
      "attributes/serial"
    ]
  }
]

One example use case behind this:

• We want to always get the definition of a Thing to "know" its current thing model (and semantic version of it)

[alstanchev]

I was thinking about the possibility if the modification is coming from a ditto connection that maybe there with a header mapping we can define extra fields, This header will be checked at the place where the static config is used and extend the functionality to also work without the static config but per connection config.
@thjaeckle What do you think for such an extension to your aproach?

[thjaeckle]

The "problem" I see with this approach is that the "producer" of a change to a Ditto thing can not be aware of all the consumers ..
That's why I think configuring it at the "source connection" is not really feasible.

In a very closed system this might work - but then also the static configuration works well ..

The approach could be extended with that approach - the "source" defining some "pre defined" extraFields to emit (just as an additional Ditto header), I would however rather move this to another follow-up issue - as we do not have a practical need for that as part of this issue.