access to id, service and subservice in jexl context for functional test

[AlvaroVega]

fix for #1523

[AlvaroVega]

groupToIoTAConfigType is not providen deviceId

Maybe testUtils.testCase should do that

[fgalan]

I think it would be wise to use same literals than the one used at CB (https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/orion-api.md#macro-substitution)

• id: for the id of the entity
• type: for the type of the entity
• service: for the service (i.e. fiware-service header value) in the
  update request triggering the subscription.
• servicePath: for the service path (i.e. fiware-servicepath header value) in the
  update request triggering the subscription.
• authToken: for the authorization token (i.e. x-auth-token` header value) in the
  update request triggering the subscription.
• All the attributes in the entity triggering the notification (included in the update triggering the notification or not)

Is the PR working that way?

[AlvaroVega]

Is the PR working that way?

Not. This is just to align functional tests with implemented feature in iotagent-node-lib, specially test about jexl context

[fgalan]

Is the PR working that way?

Not. This is just to align functional tests with implemented feature in iotagent-node-lib, specially test about jexl context

CB uses servicePath. IOTA uses subservice. They are different but probably is not a good idea to change any of them to align, due to potential backward compatibility problems and changes in the IOTA DB model.

[mapedraza]

LGTM