[RPC][Mining] Add sanity checks to generatecontinuous

[CaveSpectre11]

Note

This is built on top of #878 and requires code added in #877 and #878

Problem

generatecontinuous can get users in trouble by not knowing what their settings will do to their resources

Solution

Add checks in generatecontinuous:

• Warn if RandomX is set to less than 4 threads.
• Warn if Sha256D is more than one thread less than the number of cores
• Provide ability to override the warnings with a new optional parameter
• Disallow generatecontinuous true if already running
• Rework the result of the command to provide a JSON status

Testing

$ veil-cli generatecontinuous true 1
{
 "success": true,
 "algorithm": "sha256d",
 "threads": 1,
 "message": "Mining started"
}
$ veil-cli generatecontinuous true 1
error code: -32603
error message:
Mining already active
$ veil-cli generatecontinuous false
{
 "success": true,
 "algorithm": "sha256d",
 "threads": 0,
 "message": "Mining stopped"
}

$ ./veil-cli setminingalgo randomx
{
  "success": true,
  "message": "Mining algorithm changed from sha256d to randomx"
}
$ veil-cli generatecontinuous true 1
error code: -8
error message:
Error: RandomX must be at least 4 threads

$ veil-cli setminingalgo sha256d
{
  "success": true,
  "message": "Mining algorithm changed from randomx to sha256d"
}
$ veil-cli generatecontinuous true 100
error code: -8
error message:
Error: Available cores: 4, limit sha256d to 3 threads
$ ./veil-cli generatecontinuous true 4 true
{
  "success": true,
  "algorithm": "sha256d",
  "threads": 4,
  "message": "Warning: Available cores: 4, limit sha256d to 3 threads

[codeofalltrades]

ACK b654113

[seanPhill]

All this works on mine, but I noticed when setting too many SHA mining threads that I got a reported number of cores double the number of actual cores.
generatecontinuous true 80
Error: Available cores: 12, limit sha256d to 11 threads (code -8)

I never set my SHA mining over 4, and sometimes when leaving the wallet mining for several days I come back and find it stuck, where stopping mining allows it to immediately catch up. In the above testing I was able to accidentally set an excessive RandomX number of cores, but it didn't freeze and I was able to simply set it again to a sane number.

[CaveSpectre11]

Error: Available cores: 12, limit sha256d to 11 threads (code -8)

This is going to take some digging, and probably outside the scope of the PR. We'll need to figure out why std::thread::hardware_concurrency(); returns the wrong number of cores for Mac (which may be challenging without a mac to develop on)

[seanPhill]

Just for comparison I tested it on a quad core i7 iMac with MacOS Catalina and got the same result.

[CaveSpectre11]

Little bit of research shows that hardware_concurrency returns the number of concurrent threads the system has; and can often be 2x the number of cores; but it's OS specific.

So I might need to tweak the wording here a little bit.

[codeofalltrades]

ACK 6cc4d59