Finish other half of async events system

[jakerye]

Our events can be broken into 2 major camps

1. Fast events - actions like checking thread information. These events get FULLY processed and return a 200 status on success.

2. Slow events - actions like changing device mode. These events get added to an event queue so the thread can process them when it is ready to. For example, we wouldn't want to change modes in the middle of taking a sensor reading. It is better to wait for the reading to complete, have that process check for new events and transitions then act accordingly.

We do however always want to have quick response times from our API and to acknowledge the request has been received. Returning a 200 violates HTTP protocol in this case because there is still processing to be done. It is better to return a 202, or "Accepted" then provide a new task endpoint with an approximation of remaining processing time for the client to call for receiving the full response.

In practice, so far, checking for the post-202 response has not been vital to operation however it is a critical feature for a comprehensive and robust event processing system. This new task endpoint has not been developed yet and it is what this feature request is referring to.

Also in the process of building this out, it will be important to update the 200 response codes to 202s as this design pattern has not been rigidly followed from code inception.

I'm sure what the best way to do this is yet...perhaps an event response queue in the manger with an event ID? So client would POST to /upgrade/response/ with a payload including "id" (could also be a detail route) ... need to handle this for the peripheral events as well which is a bit more general case than the upgrade / resource threads.