Calling `SecAccessControl::create_with_protection` with None fails

[brotskydotcom]

The call SecAccessControl::create_with_protection takes an optional protection mode argument, which implies that you can supply None to get some sort of default protection mode. But you can't. Providing None as the protection mode defaults to using a NULL protection argument to SecAccessControlCreateWithFlags, but this fails. (Per the Apple docs on this call, the value supplied must be one of a specific set of values.

This problem also makes attempts to use the PasswordOptions::set_access_control_options fail, because that call uses a None protection class when creating a SecAccessControl value.

It's not clear to me what the right fix for this is. Probably the most expected fix would be to pick an allowable default value for protection mode, but it's not clear what the default should be. My suggestion would be kSecAttrAccessibleWhenUnlocked, which would then take effect for PasswordOptions::set_access_control_options as well.

While changing a default is not backward-compatible, it's not clear to me how there could be any working code in the field that actually supplies None. It's difficult to do testing of this code, because setting access controls requires you are in an app that has a provisioning profile, and no command-line tools (such as test code) can possibly operate with a provisioning profile. (I can't find any older versions of iOS or macOS that accept a null protection value, so I don't think this code just predates the restriction that's breaking it now.)

Anyway, I'm happy to contribute a fix for this, if the maintainers are interested and have opinions as to what the default should be. It's a trivial change, and I've tested it in apps with a provisioning profile. (See also #226 and #227, which provides a workaround for this problem by letting the client construct the access control profile directly.)