Create async matcher

[ocvit]

Async backend considerations:

• concurrent-ruby - thread-based, compatible with basically everything, including different Ruby implementations, provides thread-safe primitives (of questionable reliability, haha)
• async - fiber-based, can be a little bit more performant than concurrent-ruby (with correct setup), has worse compatibility with gems (especially the ones that incorporate C-extensions), as well as with alternative Ruby implementations, no thread-safe primitives out of the box
• ractors - x2 faster than regular threads, more restrictive than Rust's borrow checker with lifetimes of mutable references in async fn's, not compatible with basically any of the popular gems, even with the standard ones like net/http, not compatible with C-extensions

And the winner is - concurrent-ruby.

Though, there is really high temptation to throw it out in a favour of pure thread-based setup similar to the one used in parallel. Downside - no reusable pools. Upside - threads are killed after being used immediately, so no need to worry about thread pollution. Thing that should be tested first - how much thread allocation "on-demand" affect the performance.

Async setup:

• concurrency level of asynchronous contract checks can be limited with fixed main pool
• asynchronous execution of rules is available, but disabled by default, as it leads to more rules to be checked than minimally required (comparing to sync mode); on the other hand, contract check completes much faster
• comparison of different pools configs can be checked in benchmarks
• while there were no problems with sampler and logger under stress, technically they're still not fully thread-safe; possible solution - to move their initialisation from contract to Matcher, so each check will work with its own isolated copies