Add a higher-level AuthenticatorService that can query multiple backends

[jcjones]

This patch adds a new trait AuthenticatorTransport for the existing manager.rs's U2FManager to implement, and a higher-level AuthenticatorService that registers AuthenticatorTransports and queries them.

This starts down the road of adding in additional authenticator/transport implementations to be queried simultaneously, including reworking the callback function to have an observer which cancels other transports (see clone_and_configure_cancellation_callback in authenticatorservice.rs). It does not add any new transport types, which will be done in their own PRs.

[Crote]

That's a lot of wat I was missing for #114, yeah!

There seems to be one subtle "gotcha", though: AuthenticatorService should probably wrap callback, so that AuthenticatorService::cancel is called as soon as the operation is successful.
Currently, the caller must manually do this, even if the operation is successful. If they don't, everything will seem to work but the other transports will keep trying to do the operation and stuff might go horribly wrong. It seems like this would result in a memory leak because the channel is never closed due to a Sender not being dropped?

Something to think about is what exactly AuthenticatorTransport should expose. The register / sign pair seems obvious - especially considering the current U2FManager, but pretty much all transports must implement the same logic handling the APDU commands representing this. In #114 I made the decision to define a transport as "something accepting APDU commands", perhaps that's something to look into in the future? Maybe AuthenticatorTransport should just expose a detect_devices function so that AuthenticatorService gets APDU-talking devices to pass to a StateMachine? Does U2FManager even make sense anymore?

[jcjones]

Those are excellent questions that are running through my head, too. Right now I'm sort-of-testing this PR by adding a WebDriver Virtual Device tool, which nearly is wired up (and will hit the cancel issue, so thanks for that!). But after the refactor in #124 it absolutely raises whether U2FManager should just refactor out, but I don't yet see exactly how I'd want to decompose it.

Still, glad that I'm heading the direction you were imagining, too. I'll get my virtual_devices WIP patch up later tonight, once the basic bones work. (It will take me some time to write a token, but I'm getting the warp-based web API running alongside it)

[jcjones]

https://github.com/mozilla/authenticator-rs/tree/virtual_devices doesn't have the cancel fix, but it sort of starts the sketch of how non-HID devices might interact with authenticatorservice.rs, which is why I'm not framing it in APDU form as-of-yet, but that's still a thing I'm noodling over!

[jcjones]

OK, cancel fix is in here. I'm going to eventually split this into more logical PRs rather than this monoith I let this become, but I want to make sure if the direction before I ask for more review, and I don't see a reason to split until I'm ready for review.

[rmartinho]

Looks good to me :)