refactor thread and asio usage in state history plugin

[spoonincode]

Some usage of asio in state history plugin looks at odds with typical asio patterns. For example: needing a connection to call an explicit close() function after a failure occurs (normally you'd just let the shared_ptr fall out of scope to dtor it), and some sort of stopping variable (normally you'd just stop() the io_context which then ensures no callbacks are running, and then just let everything dtor itself). To be fair there may be yet-undiscovered-to-me reasons these are required, but so far I haven't seen it.

state history plugin is also very loose and haphazard with how it handles its thread, oftentimes punting back and forth between main thread. Yet, it seems like state history plugin's thread usage could be awfully simplistic: build up blocks' traces & deltas on the main thread and then when on_accepted_block() simply post() over to ship's thread which then does everything it needs to entirely on the ship thread without ever needing to go back to main thread.

Resolving the above issues will make it significantly easier to reason about state history plugin's flow and will be less prone to introducing failures.

[heifner]

• Currently block data for SHiP is pulled from forkdb or blocklog. SHiP does not store blocks in its log files. SHiP optionally stores traces and table deltas in its logs. Default options for SHiP actually pulls all data it serves from forkdb/blocklog.
• forkdb was recently made thread safe. Blocklog is current not thread safe.
• Blocklog could be made thread safe and then SHiP could pull the data it needs from the SHiP thread(s) without needing to post() onto the main thread.

[spoonincode]

There are other benefits to allowing blocklog to be thread safe, such as net_plugin being able to pull requested blocks from it on while on net threads, so seems like this would be good improvement to hit first