fix issue where start will never resolve if droplet has been deleted

[trevj]

Currently, the start method assumes that it can fetch the details of a droplet it's just created - that was originally a reasonable approach but not since we introduced cancellation. I believe this partially addresses:
UWNetworksLab/uProxy-p2p#2397

---

This change is

[jab]

can we break out of this loop once we set this here?

[trevj]

Sure! Some functional programming approach would be even better...but can wait.

[jab]

Very nice changes. (Two totally-safe-to-ignore nit-questions so) 👍

[jab]

(Just for my own understanding, the main change I saw here is to deal with the droplet value directly rather than wrapping it in an object like {droplet: droplet}. But I can't tell why that would fix the issue where start won't resolve if the droplet has been deleted. Can you point me toward where that makes the critical difference?)

[trevj]

Quite right, I didn't explain: previously, start made a GET call to /droplets and (erroneously) assumed the response would have a droplets field - getDroplet_ makes no such assumption. Basically, yay utility functions :-)