Run Android certificate verification on worker thread

[FrankenApps]

This is an attempt to fix #256.

I think the general approach should work, but I am not very confident in the error handling part, yet.

[djc]

This seems fairly heavy-handed, as it spawns a thread even if the caller was already verifying from a non-main thread?

[FrankenApps]

I see. I added a check to only spawn the thread when needed and updated the tests.

[complexspaces]

Hi and thanks for the PR,

I'm not sure this is how I would go about implementing the worker thread idea I proposed in the original issue. This approach seems to generate a lot of overhead checking what thread is currently in use (as its using more JVM calls instead of libc) and spins up a brand new thread for every TLS verification performed (which, in a busy application, may be a lot of calls over the process' lifetime).

If we are going to do per-thread verification offloading, it might be better to just let Kotlin handle the thread management by using a Dispatcher pool so that threads can be efficiently reused across calls and gracefully scaled down by the OS.

The first approach I was going to try and benchmark next week would have been a persistent background worker that all verification requests were forwarded to. This would have also removed some JVM thread attachment overhead too since now this library would only ever attach one thread instead of N for however many Tokio worker threads happened to invoke this code. The idea needs measurement though because its not clear to me yet if the platform verifier can actually run perfectly concurrently (even if #189 was cleaned up) or if there would be a blocking synchronization point anyway.

[FrankenApps]

Sounds reasonable. I haven't really measured anything yet (as I wasn't even entirely sure if the issue is fixed for good with this), so I'll close this for now.