Increase default rpcthreads to 8 #5345

When solo mining, BFGMiner makes use of 3-4 long-lived connections: 1 for longpolling, 1 for submissions, and 1-2 for its own getblocktemplate calls. This barely fits with the default rpcthreads limit of 4, and means that when it has the total of 4 connections open, users cannot run any RPC calls of their own until one is closed by bitcoind timing it out. Ideally, we shouldn't block on idle connections, but while we do, increasing the default thread count to 8 seems reasonable IMO. Asked on #bitcoin-dev the other night and got no input, so I'm guessing nobody much cares.

Adding threads implies a fair amount of memory utilization due to per-thread stacks and assorted overhead, so I care. ... we've been working hard to reduce memory usage to make bitcoind fit on smaller VPSes and such, and this would take back much of the gains.

Note sure this is the right thing to do, perhaps there should be a new thread allowed for user initiated RPC calls if the default 4 are stalled/utilized? Just raising to 8 could just lead to similar problems in the future.

NACK for now.

• Threads take up memory (8MB or 4MB per thread on 64 and 32 bit). This is virtual memory, but on 32 bit systems that's a rare commodity - yes, this could be configured...
• Our level of parallelism is bad. 29 out of 39 non-wallet RPC calls keep cs_main locked all the time. This includes most calls that actually take time to compute.

I'd prefer just documenting the option better.