Review /takeoff and /arm endpoints

[i25052i]

Context

A while back in #61 and #63 we made it so the drone would take off immediately if armed when the /takeoff endpoint was called.

Recently, #67 altered mode-changing behavior during takeoff. Instead of setting the drone to AUTO and taking off on our own, we wait for the operator to set the drone to AUTO in the takeoff endpoint.

This means that the /takeoff endpoint now does not return a response until either the operator sets the mode, or the grace period expires. It can now take up to 15+ seconds in the worst case to return a response from this endpoint. This is necessary to return an indicator of whether the takeoff was successful.

Task

• Investigate whether we should remove the feature of the /takeoff endpoint notifying callers of the takeoff's success in order to ensure the endpoint returns quickly.
• Callers would have to check by themselves afterwards (such as looking at whether the drone's altitude has changed) to infer if the takeoff was successful.

[i25052i]

Also:

• these endpoints might have broken sometime around when Feature/mode changes #73 was merged.
• See GET /land endpoint not working #77 as well

[i25052i]

We have recently observed behavior where the simulated aircraft does not autonomously take off when the mode is set to AUTO (prerequisites of having a takeoff mission and being armed were satisfied). This turns out to have been a copter-specific issue - the takeoff procedure we established last year still works for plane SITL instances.

We will return to this issue after the requirements are better understood in #95.