re-add getDeviceById

[jason-fox]

Fixes #1624

Checking with NGSI-v2, 4c44db307f2e2723c4c8a47fdde462ced28ba754 is fine, 964ee270fea64d36c1872e3050dd45031071bd59 onwards manifests an incorrect payload as:

 "undefined": {
    "type": "None",
    "value": null,
    "metadata": {
    "TimeInstant": {
        "type": "DateTime",
        "value": "2024-06-27T09:28:53.963Z"
    }
}

The only config functions that has changed at this point is getDevice() where the fallback to getDeviceById() had been removed

function getDevice(id, apikey, service, subservice, callback) {
    getDeviceById(id, apikey, service, subservice, function (error, data) {
        if (error) {
+            // Try without apikey: apikey will be added to device later
+           getDeviceById(id, null, service, subservice, function (error, data) {
+                if (error) {
+                    callback(error);
+               } else {
+                    callback(null, data);
+               }
+            });
-            callback(error);
        } else {
            callback(null, data);
        }
    });
}

Re-adding the code fixes this direct issue - although linked entities are still not present in NGSI-LD

[jason-fox]

@AlvaroVega - Since the apikey service plus apikey on device workaround works ✅ - it is up to you to decide how to proceed here.

Either accept this PR to maintain backwards compatibility, or reject the PR and properly document this change of behaviour as a breaking change.

[AlvaroVega]

But with this is not possible define two devices in de same service/subservice with the same id but different apikey.

[jason-fox]

That still leaves you with two choices 😄 :

1) Document the breaking change as a breaking change. 2) Add a start-up parameter or ENV variable to either:

• maintain backward compatibility (as in the PR)
• allow define two devices same id different apiKey

I would assume the breaking change path is more likely to annoy existing users who are looking to upgrade, but the flag for old functionality is a maintenance debt.

At least if I'm upgrading from 4.3.0 to 5.0.0 I'm more likely to throughly test the setup and more likely to look at the release note.