NGSIv2 based forwarding for CPrs

[fgalan]

NGSIv2 based forwarding (i.e. forward NGSIv2 queries/updates from CB to CPr, based in existing registrations) has not been yet defined.

First task with regard to this issue is specificaiton of the mechanism. In order to do so, I have recovered some previous discussion on PR #2990 comments that may be useful.

@jmcanterafonseca comment:

First of all a context provider in theory should be just as any other context broker i.e. supporting the same set of APIs. Having said that I have to acknowledge the fact that Orion Broker main use case for context providers is the integration of external datasources and in that case we can not force developers to implement all the stack, and as a result my proposal is:

The operations that would have to be supported by an NGSIv2 context provider are:

/v2/entities?type=XX,JJ&id=YY,ZZ&attrs=at1,atn

I assume that at this stage we don't want to forward full query requests i.e. q parameter,

We need essentially to support the attribute PATCH method so that we can forward update requests >properly i.e. currently we have many many flavours for operations in charge of changing an attribute >but the essential one is PATCH, so that's why this is proposed.

/v2/entities/<entityId>/attrs

What do you think?

@fgalan comment:

Regarding the operations I guess you mean (in your previous comment verb is missing):

GET /v2/entities?type=XX,JJ&id=YY,ZZ&attrs=at1,atn
PATCH /v2/entities/<entityId>/attrs

I think it may sense. Next step in this line would be to include that "CPr requirement" in the
specification in this PR along with a functional explanation on how forwarding works (paying special attention to "multi forwarding" case, e.g. a query on entity E ends in a forwared query for E-A1, E-A2 and E-A3 as E-A{1|2|3} belong to different CPrs).

This specification could be either in the .apib (if we agree forwarding is part of the NGSIv2 API) or specific .md in the Orion manual (if we agree on the opposite), which I see by your last comment #2990 (comment) is yet a matter of discussion.

PD. I agree ?q shouldn't be a requirement for CPrs.

Second task regarding this issue is to implement the mechanism in CB.

CC: @dcalvoalonso as the specified mechanism is relevant in the context of the IOTAs NGSIv2 implementation in which you are involved (pasive attributes and commands).

[kzangeli]

Two important things, major drawbacks in v1 forwards:

1. At entity creation, if the entity is covered by a registration, then the creation should fail.
   This is tricky, depends on attributes, service path etc.
   However, the infamous "shadowing" problem of APIv1 forwards is solved with this.
2. If more than one context provider is found for an update/query, all of them (not just the first one
   that mongo returns) must be forwarded to.
   Also not easy, if we have a query to forward to 6 CPrs, and all of them have a different value for an
   attribute, which one do we choose? Using timestamps perhaps ...