Add support for fetching OTP from shell

[webmakersteve]

First contribution here. Happy to make some changes.

This allows for fetching OTP from an arbitrary shell command which works great for my password manager! I am running this locally myself but would be happy to make any changes required to get this into mainline.

I know everything needs to be localized as well. I will be happy to do that if this is a change you'd accept.

[KazWolfe]

Ref #1378 and #1433 here are related art.

I like the general concept here, and it would certainly be helpful to make MFA flows for those of us who use password managers nicer. It would be great if you could add some documentation on how to set this up, I'd think.

Otherwise, if you wanted more work in this specific area, perhaps check out the above-referenced #1433 - it might be a bit better of an overall use of time. I do have some worries that if we start adding in Too Many Systems to resolve OTP/credentials (since this is now our fourth proposed mechanism), it could get a bit frustrating to maintain in the long run.

[webmakersteve]

I took a look at the issue WRT adding an pluggable auth system. I thought about doing it a bit more generically when I first did this but didn't want to spend too much time if it was not something anyone was interested in - guess I should have taken a look at PRs and issues first!

The lightest weight way of doing this type of plugin system is doing it something a la protobuf plugins which just uses shell STDIN and STDOUT with a specific protocol as a way of ferrying data between processes, especially when the system is as light as this one (just literally loading account credentials).

I'm not sure how much the app benefits from having a full pluggable system. I guess it is nice because the app wouldn't need to store any credentials (username, password, or whatever else) but I figure the only dynamic piece of auth information most people are dealing with is their OTP.

In lieu of that, configuring the app to load all C# assemblies in something like a plugins/ path dynamically and loading those into the classpath would be the next easiest. I can look at what i've done here and adapt it to that, and the HTTP server feature can maybe just be added to a plugin in that case.

[KazWolfe]

The lightest weight way of doing this type of plugin system is doing it something a la protobuf plugins which just uses shell STDIN and STDOUT with a specific protocol as a way of ferrying data between processes, especially when the system is as light as this one (just literally loading account credentials).

We were thinking of being fancy and having communication via a proper plugin system, but honestly even just JSON over stdin/stdout would be enough. That's more for the other thread than here; more putting out the general concept of where one can take this were they to want to go down that path. The main thought behind plugins was that we could have more complex functionality without requiring people go all out with shell scripts and the like (e.g. Yubikey support).

I do generally agree that pure OTP fetching is probably enough for the vast majority of users, but if we overengineer a bit, why not just go all the way? While I'm not an XL maintainer, I do think there would be interest from that side were someone to actually build a decent (and reasonably secure) solution for this.

At the very least, tentative +1 for this, just with the general concern that were we to keep adding more mechanisms, it'd become a bit annoying to deal with in the long run.