Implement command pipelining (threadpool)

[wscalf]

Process would involve a general threadpool and a script threadpool, and a basic job system
Each job has an associated threadpool it can run on
When a job completes, it can output more jobs to be scheduled
This allows event handling to follow roughly the pipeline-

• Decode (turn the event into a job to run the code)
• Execute (run the code)
• Output (run through a template to generate and send output

Though it doesn't necessarily have to follow exactly this pattern- input might decode into an incomplete chunk, and we need more data, so it gets buffered with no additional jobs generated. Or maybe there's an error, so it goes straight from Decode to Output with no need to Execute. An Output job might fork if there are multiple recipients with different client types so there's one job per client type creating and sending separate responses in parallel.

Script code however must run single-threaded, and the data being operated on by parallel jobs must be static, so the decode portion must be possible with minimal data that can be synchronized in some way, and data made available to output jobs must be copied during the execute phase. As long as modifications happen only in the execute phase, this can be done without locks.

Note: this approach requires significant rearchitecture and is intended to increase throughput for high-traffic MUDs on multicore systems. It's worth asking if this is a valid case at all versus leaving the whole system single-threaded. How many players does it take for that to start to introduce lag? And how many players can a game realistically draw?