cfg-gate default credential builders so keyring builds on all platforms

[phlip9]

Hi, I'm currently attempting to use keyring for a cross-platform app. One of the platforms (Android) doesn't have a default backend, so I've resorted to stuffing the credentials in the app's data directory for the time being. I've got that alternate CredentialApi impl built, but sadly keyring won't build for android for a small reason: there's no default module.

$ cargo check --target=aarch64-linux-android
    Checking keyring v2.0.2
error[E0433]: failed to resolve: use of undeclared crate or module `default`
   --> src/lib.rs:176:54
    |
176 |         static ref DEFAULT: Box<CredentialBuilder> = default::default_credential_builder();
    |                                                      ^^^^^^^
    |                                                      |
    |                                                      use of undeclared crate or module `default`
    |                                                      help: a struct with a similar name exists: `DEFAULT`

error: could not compile `keyring` (lib) due to previous error

To get around this (but still use the common keyring API across all platforms), this PR #[cfg(..)] gates build_default_credential, Entry::new, and Entry::new_with_target. That way they're only visible on platforms with default backends available. Unsupported platforms will get a compiler error if they try to use the default constructors.

Another approach would be to make it a runtime error rather than a compile-time error. Something like:

fn build_default_credential(..) -> Result<Entry> {
    cfg_if! {
        if #[cfg(any(target_os = "linux", ..))] {
            // existing fn body
        } else {
            Err(Error::NoDefaultBackend)
        }
    }
}

Otherwise keyring is working well for me : )

[brotskydotcom]

Hey Philip, thanks for this PR. A couple of things:

1. Would you please open an issue regarding the inability to build on Android? That way there's a "reason" for the PR.
2. Both the approach in this PR and the one in your comment feel a little heavyweight to me. Since the mock backend works on all platforms, can you alter your PR instead to use the mock backend on other platforms?

Thanks again for using keyring and providing feedback - it's a great feeling to hear from customers :).

[brotskydotcom]

See my comments in the PR - I think we can simply use mock as the default on other platforms.

[phlip9]

Sounds good! I've switched the approach in the latest commit--we'll just default to the mock backend on unsupported platforms.

[phlip9]

I've also left an issue that covers some potential approaches for a default Android backend: #127