Use variable move mission

[aaronchongth]

Fixes: #7

• Move missions should be a predefined variable mission, so no additional missions are posted to the MiR server whenever commanded.
• Docking uses a predefined mission too.
• A charge finishing_request, executes the dock command successfully, tested on hardware, however once docked and charging starts, it was found that the fleet adapter is unable to interrupt it and send new commands even though the robot is fully charged, charge finishing task can't be interrupted #17

[mxgrey]

I left a few comments, but I wouldn't consider them to be blockers.

[mxgrey]

I have one general concern related to the implementation of this fleet adapter.

On this line and this line we're looking at the state reported by MiR, and if it gives us a READY result then we assume that it has reached the last waypoint that we commanded to it.

However, what happens if the system falls out of sync? For example, what if the following sequence happens:

• fleet adapter sends mission request,
• fleet adapter requests task state
• MiR receives task state request and issues response that the robot is Ready
• MiR receives mission request
• fleet adapter receives confirmation of mission request
• fleet adapter receives response that robot is Ready, which is taken to mean that the last mission request has already succeeded

This sequence may be improbable, but unless there's something in the REST API library to guarantee that the REST request/response ordering is FIFO, we have to consider that this sequence is possible. Packets dropping over wifi with TCP resending the requests + responses could allow this sequence to happen. I've certainly witnessed this kind of behavior in async systems that don't have message ordering guarantees.

[aaronchongth]

Yeah I can see that happening in rare scenarios, #20.

I'll try to get it addressed in the next overhaul.