Transports field for protocol

[Cerfoglg]

The purpose of this change is to add a "transports" array field to the IoT Manager's Protocol model, in order to be able to list the transport protocols that an IoT Agent supports.

[fgalan]

After recent merge of PR #196 has introduced changes in master that cause some conflicts on this PR. They should be fixed to make it mergeable again (maybe @jason-fox , author of PR #196, could assist you during the process).

However, not sure about the feature implemented by this PR. We have two doubts:

• Why could be useful to store in the IOTA Manager the transports of the agents? Who is going to consume that information? Which use case is behind this? Note that IOTAManager doesn't manage transports (as it doesn't manage measures). The IOTAManager only manages configurations.
• We are not sure about backward compatibility of the feature.

[jason-fox]

@Cerfoglg - all you need to do is merge and accept yours

Thereafter

npm i
npm run lint

And fix any es6 errors raised. (Alternatively you could disable the failed rule for your files if necessary)

[chicco785]

The support of transports is meant to facilitate configuration. By knowing which transports and agent support, you can facilitate their configuration and the deployment of devices.

[AlvaroVega]

IMHO default transport is a field that only make sense at device model only, not at protocol config level. Iotagent manager is currently redirecting and then showing if a device has that field.

[chicco785]

IMHO default transport is a field that only make sense at device model only, not at protocol config level. Iotagent manager is currently redirecting and then showing if a device has that field.

which Transport you pick is at the device level, but which transports are supported by the agent, it's at the agent level. How can you know if agent x supports transport y? because you read it in a manual? :)