IoTScape Cybersecurity features and RoboScape reimplementation

[gsteinLTU]

With NetsBlox/NetsBlox#3001, IoTScape is implemented in a way that allows devices to add new services. However, the full goal of IoTScape was to allow the same educational cybersecurity features from RoboScape to be used with new devices.

Devices will need to have a way to configure their security settings from their end as well (mostly for pre-encrypted challenge robots), and a way to send commands to be resent to them (again, for RoboScape challenges).

To support the RoboScape simulator's custom robot types, it may be desirable to replace the RoboScape service with an IoTScape-connected service that allows existing robots and new robots to use the same blocks. If that proves difficult, refactoring some features (like the ciphers) into a separate utility would be a good idea, as now there would be at least three services using them.

[gsteinLTU]

These features will need a way to "link" together multiple devices that are really parts of a larger whole. E.g. a robot with multiple sensors as "DistanceSensor" devices would need to make sure all parts are encrypted with the same key (and reset together).

[gsteinLTU]

NetsBlox/NetsBlox#3274 includes some elements of this already, keys/ciphers are now usable with IoTScape devices for sending commands.

Still needed:

• [x] "Linked" devices sharing encryption settings (must be set on "main" device)
• [x] Commands reflected to listening users (with encryption)l
• [x] Encryption applied to events/messages from devices (disable "basic" messages when encrypted)
• [x] Ability for devices to request "hardware" keys (may need hardware to test with)
• [ ] Ability for devices to set their encryption settings from the device side
• [ ] Access control through similar system to RoboScape (possibly generalized to handle both so eventual reimplementation is smooth)

[gsteinLTU]

@gsteinLTU listen-specific events should be included in getMessageTypes