geli: use a single crypto session for each provider

[asomers]

Summary

geli: use a single crypto session for each provider

Previously, geli would use a separate session for each worker. Using a
single per-provider session simplifies the code and saves memory.

Test Plan

The geli test suite with software, aesni, and padlock engines

[jhb]

Is the issue you mentioned previously that you are worried that some drivers might not support concurrent requests on a session? I can't recall if all drivers are ready for this. ccr(4) is at least, though it will perform better if you use separate sessions (Chelsio NICs have multiple crypto engines and each session is tied to a specific engine).

That said, the issue from PR 242747 seems more to be that there are too many threads active? Does it make sense to use a single pool of worker threads shared by all geli devices instead of new threads for each device?

[jhb]

A suggestion from pjd@ at the fall summit this week is that for OCF sessions with a synchronous backend we should just dispatch the crypto request directly from the g_up/g_down threads instead of kicking the requests off to a thread pool.