Make better use of multi-core servers

**User Story**
As a `node operator` I want to `make better use of my server hardware` so that `my server can process more transactions per second`.

**Impacts**
Describe which portion(s) of BitShares Core may be impacted by your request. Please tick at least one box.
- [ ] API (the application programming interface)
- [ ] Build (the build process or something prior to compiled code)
- [ ] CLI (the command line wallet)
- [ ] Deployment (the deployment process after building such as Docker, Travis, etc.)
- [ ] DEX (the Decentralized EXchange, market engine, etc.)
- [ ] P2P (the peer-to-peer network for transaction/block propagation)
- [x] Performance (system or user efficiency, etc.)
- [ ] Protocol (the blockchain logic, consensus, validation, etc.)
- [ ] Security (the security of system or user data, etc.)
- [x] UX (the User Experience)
- [ ] Other (please add below)

**Additional Context (optional)**

@clockworkgr discovered this attempt to parallelize signature verification: https://github.com/neuronplatform/neuronplatform/commit/3b545d298f7499120220b06eb1449386d9b8099d

I think a better approach would be to extract the crypto calculations from the database thread out into the network layers, i. e. handle the signature->pubkey conversion in the P2P and API layers. Keep in mind that a witness has will apply a given transaction three times when signing a block:
* when the TX is received before it's included in a block
* when building the block
* when applying the newly generated block

The abovementioned patch doesn't help with steps 1 + 2.

## CORE TEAM TASK LIST
- [ ] Evaluate / Prioritize Feature Request
- [ ] Refine User Stories / Requirements
- [ ] Define Test Cases
- [ ] Design / Develop Solution
- [ ] Perform QA/Testing
- [ ] Update Documentation

The issue names no files or tests; start by reviewing the linked signature-verification parallelization commit and tracing the three transaction-processing stages described in the body. Done would require a defined approach for moving crypto calculations out of the database thread, with test cases and performance validation identified.

Written by the indexing model from the issue text.