Investigate a better concurrency model or description

[lalexgap]

Right now the way concurrency works in our test can be kind of hard to understand. We specify a ConcurrentPaymentJobs value ( typically from 1 to 50).

This is the number of payment "jobs" a client maintains. A payment job is the process of

• opening a virtual channel
• sending a few payments on it
• close the virtual channel

We run these jobs in their own go-routine which means the client handles concurrent API calls (which it handles fine).

I think this model works fine although may be resource intensive for large ConcurrentPaymentJobs values as we're spinning up a go routine for each job.

However I'm not sure this model reflects how we'd expect it to be used in retrieval market. It's also hard to quickly describe what this value means. It would be nice if the way we controlled load (concurrent or otherwise) was simple to explain and understand.

In the context of a retrieval market is there a better way to model load on a client? Is there any way we could simplify our model so it's easy to describe and understand?

[lalexgap]

Based on standup discussion (see https://www.notion.so/statechannels/Benchmarks-and-metrics-for-testground-e40facd47c7d4487bb8e1a2836690bb5) we've decided that the current "concurrency" model is good enough. Closing for now.