Create pure rust macos backend (using IOHidManager)

[ruabmbua]

• Remove dependency to signal11/hidapi
• Match previous macos backend features

For this issue help is wanted. I have no experience at all with MacOS, and also no access to apple hardware.

Progress:

• Device enumeration
• Device meta data extraction
• Blocking HID IO
• Non-blocking HID IO
• Setup CI (travis might be a bad option for macos)

[jleni]

I can also help with MacOS.
I would suggest switching to circleci and requesting build machines for macos (https://circleci.com/pricing/#faq-section-os-x). Travis mac builds are very slow.

[ruabmbua]

It`s not just for CI. I need something to develop on. I guess setting up macos in a conventional VM should do the trick?

[jleni]

I understood that. I can help with the mac development. My suggestion was to add CI too.
Given that you are the owner of the project, I was suggesting you contact circleci so you can get free a OSX builder for this repo.

[ruabmbua]

Okay I got it. Anyway I will start with linux, but it might take some time. I will probably do some work on monday, I got lots of time on a train trip.

Note to myself: Do not forget to bring a hid device 😅

[micolous]

I have some macOS bindings that I'm trying to find a place to upstream. I've got another (private) fork of these, where I'm trying to pull out the FIDO-specific bits and make it a little more featured, and have fixed up some bugs.

Relatedly, on recent versions of macOS, hidapi triggers a requirement for "input monitoring" permission, because it it sets IOHIDManagerSetDeviceMatching(NULL), which is scary (or triggers alert fatigue). When an application sets a reasonable matching policy (for non-keyboard/mouse usages, or for a small set of VID/PIDs), then that permission is no longer required.

There's similar "device matching" rules available on Windows which could be made equivalent. UWP apps appear to have a similar permission gate around them, but it's not clear to me how that actually works (eg: does an AppxManifest cause those APIs to return filtered results with no further intervention).

I mention this as it'd mean expanding hidapi-rs' API further to accommodate this.

[micolous]

I now notice there's #131; I've left some notes on there.