feat: run deal filters in parallel

[LexLuthr]

Fixes #1733
This PR moves processesOnlineDeals and processOfflineDeals to their own goroutines.
Possible side effects:

1. Multiple CMD execution of custom filters in parallel (High CPU utilisation depending on the number of deal being processed)
2. The deal rejection will not be in order anymore. Say, we get deal A first and deal B later and start processing them. It is possible for deal A to be rejected for lack of resources and deal B to be accepted depending upon which goroutine finishes first.

DO NOT MERGE

[LexLuthr]

Tested on devnet:
Sent 1000 deals in a for loop from bash with no sleep time.

real    15m16.104s
user    3m48.002s
sys     2m34.272s

Not a single deal timed out. Every deal was responded to correctly by either accepting it or rejecting it.

[masih]

Suggested change

	sendErrorResp(&acceptError{error: err, isSevereError: true, reason: "server error: starting deal thread"})
	sendErrorResp(&acceptError{error: err, isSevereError: true, reason: "server error: setting up deal handler"})

[masih]

Specify keys in struct and avoid setting zero value fields (i.e. err)?

Suggested change

	dealReq.rsp <- acceptDealResp{&api.ProviderDealRejectionInfo{Accepted: true}, nil}
	dealReq.rsp <- acceptDealResp{ri: &api.ProviderDealRejectionInfo{Accepted: true}}

[masih]

• Ditto; see previous comment.
• Can we do something about duplicate code?

[LexLuthr]

I have refactored to reduce the duplicate code and fix the RSP channel responses with specific keys.

[nonsense]

@LexLuthr I see you posted numbers on how this perform with the new code (this PR). Could you also post numbers on how the code performs on current main, i.e. without these changes? Not necessarily 1000 deals if that's too slow, but some numbers for us to understand the impact of this PR. Thanks!

[LexLuthr]

@nonsense I don't see much difference when there is no external filter running.

Main
real 0m53.846s
user 0m26.219s
sys 0m13.832s

Current branch
real 0m53.415s
user 0m26.272s
sys 0m12.452s

I have asked @cryptowhizzard to test it on his miner and check if there are any real world improvement in timeout rate.

We probably need to work with CIDGravity to move to a different execution mode than os.Exec to speed up the filter. Preferably an RPC call to a local process.

[LexLuthr]

@cryptowhizzard Can you confirm if you are seeing some improvement with this PR?