Update to offer NGSI-LD 1.6.1. Registration

[jason-fox]

Related to telefonicaid/iotagent-ul#573 (comment)

The NGSI-LD 1.6.1 Specification, clarifies the definition of registrations and defines operations and mode attributes to be supplied within NGSI-LD CSourceRegistrations. A default Registration is considered to be federationOps/inclusive (which is what Scorpio 3 already offers and Orion-LD 1.2 is aiming for.

This is a potentially breaking change for provisioning NGSI-LD devices - the existing functionality aligns with the Orion-LD 1.1 prototype only - there is little point in continuing to offer the provisional NGSI-LD 1.3.1. interface. Additionally properties was updated to propertyNames in NGSI-LD 1.4.1, Orion-LD offers a backwards compatible option, other context brokers may not.

How are devices affected?

1. Basic Sensors are not affected by this change
2. Sensors with lazy attributes should register as retrieveOps/exclusive
3. Actuation command attributes should register as updateOps/exclusive

The default federationOps/inclusive offers a superset of these commands so previously provisioned devices will cause unnecessary polling traffic to the IoT Agent (which the IoT Agent already rejects as unsupported see #1277).

This really isn't a big issue for this library (and the fix is really small) but for semantic versioning it would make sense to update the semantic versioning from 2.x.x to 3.x.x when it lands to indicate the move from the "experimental" operations defined in #849 et seq. which work with Orion-LD only, up to the well defined common interface supported by all NGSI-LD brokers.

[jason-fox]

An explanation of the differences between the various modes of operation can be found here

[jason-fox]

This PR will remain in DRAFT until tested against compliant 1.6.1 versions of Orion-LD and Scorpio. Looking at the comment in the Ultralight Issue, this is the current state:

1. The ETSI NGSI-LD committee defines what should happen across brokers. ✅ DONE
2. The Scorpio codebase is updated to accept registrants which are not full brokers . ✅ DONE
3. The Orion-LD codebase is updated to accept true federations . ✅ DONE
4. The IoT Agent Node lib is updated to provide whatever flags are necessary when making a registration to describe its implementation as a partial broker. THIS PR - completed ✅
   ...
5. A stable release of the IoT Agent Node lib is completed and added to the IoT Agent for JSON
6. A stable release of the IoT Agent for JSON is completed.

[jason-fox]

@fgalan @mapedraza - as you can see the change here is pretty minor, but I'd like to kick off a conversation about how you propose to deprecate the existing provisional 1.3.1 NGSI-LD registration. Would you like an entry added to the deprecated features list - what sort of timelines would you envisage etc. etc.

[mapedraza]

With respect to how to deprecate a feature, our modus operandi is to add that feature to the deprecated features list and keep it in the component for at least one release, announcing it in the changelog of the new version release, and giving at least a one-release window before removing it completely from the code base. That said, from Telefónica's side there is no problem with removing the feature completely without leaving the grace period.

As for increasing the version number, we are waiting to increase the major version number to 3.X.X when refactoring the plugins architecture and entities files (#1166)

[mapedraza]

CHANGES_NEXT_RELEASE entry is missing

[jason-fox]

CHANGES_NEXT_RELEASE entry is missing

Fixed e7896d1

[fgalan]

LGTM