RFC: Web Workflow reliability and performance improvements

[thess]

What started as an investigation of un-explained 403 errors from what I think
is a questionable CORS implementation along with interface hangs and connection
timeouts, I would like to propose the attached changes to the web_workflow
service. [Note: The CORS implementation is another topic not covered here.]

Observed problems (ESP32 platforms):

1. Listening socket closed at lower level lwip resets not re-opened.
2. User sockets being added to socket select fd lists causing errors.
3. REST HTTP recv/parsing character-at-a-time causing select thread to continuously
   run and attempt to post background task requests.
4. Active HTTP request socket not being closed or believed to be closed when it
   is still in use by select polling thread.
5. HTTP request response timeouts due to looping background tasks.

These changes address, in no particular order:

• Fixes polling thread looping forever hangs preventing new connections.
• Don't lose listening sockets on mp resets and re-init.
• Keep better separation of "system" and "user" sockets.
• Track socket states to prevent re-use of sockets before closed.
• Close REST socket when transaction completes. No post-init.
• Remove unnecessary/redundant state flags.

There may be other issues here and I am hoping for some more eyes/testing on these proposed
changes. I have been running these changes for over 2-weeks on an UMFeatherS2 now with
no loss of service. The device sleeps for 20min, then wakes and takes a number of
sensor readings and posts them to a MQTT server and adafruit.io and goes back to sleep.
The device also polls the MQTT server for notice to not sleep in order to allow connection
via Web Workflow for maintenance.

After stabilizing the ESP32 environment, I have testing these changes on the RPi
implementation. The Web Workflow processing model works fine now with both the ESP32
and RPi given the significant differences in socket handling (polling vs. callbacks).
No further work was required to the RPi socket layer as was necessary with the ESP32
sockets/lwip layer. In fact, the ESP32 implementation seems to be a lot more responsive
and on-par with the RPi now.

[tannewt]

Thank you so much for these improvements. I just have a couple of questions before merging.

[tannewt]

Thank you!