EV3 and NAO update process needs refactoring

[bjost2s]

todo

[VinArt]

This issue refers to the change in update procedures of all robots that require HAL updates: EV3 (all versions), NAO v5 & v6, raspberry pi and possible others.

This refactoring should include the development of automatic update procedures for the openroberta-connector program.

The idea is to separate the main openroberta server and the update server into two parts and make a change in the robot-server protocol.

The update could be executed as follows:

1. Robot requests version information
2. This information is used to compare current (local) and server (remote) versions
3. If versions are the same, do nothing, otherwise request a link to the update server from the main one
4. Main server sends the link to the update server.
5. Update server provides up-to-date files as resources for download
6. Robot downloads all provided files.

Current implementation of REST endpoints could be reused for this separate update server.

[bjost2s]

Another server has to be discussed in detail because of the costs, maintenance, man power, ...

[VinArt]

By the server I mean a separate software piece, not another machine. Anyway, I made a sketch of the sequence diagram for the update process:

[VinArt]

Or maybe like this: