v4: separate core library from credential store implementations

[brotskydotcom]

I am about to split this crate into several crates:

• keyring-core (the cross platform library parts of this crate)
• apple-native-keyring (the apple-native credential store implementations)
• windows-native-keyring (the windows-native credential store implementation)
• linux-keyutils-keyring (the linux-keyutils credential store implementation)
• dbus-secret-service-keyring (the sync secret-service credential store implementation)
• zbus-secret-service-keyring (the async secret-service credential store implementation)
• keyring (the CLI part of this crate done as an installable main app, plus re-export of the core library with default stores)

That will make it a lot easier to add evolve each of the credential stores separately, and for users to add new keystores independently. It will also allow this crate to have features which control exactly which credential stores get built, and to give examples of how to do this for all the different credential store crates.

The v4 release of this crate will be done once the split is complete.

[catgirlconspiracy]

Ok, so this is the actual plan now vs what's in the last rc and what's described in #232 ? I saw that yesterday and was kinda worried because for me the tradeoffs of forcing libdbus are Bad Actually. I already have zbus and tokio, and a C dependency, even vendored, is an additional complication when crosscompiling to other Linux architectures with the -musl targets. If your entire build is Rust, all you need is the target stuff from rustup, but once you have C you have to provide a C compiler (well, you can just use clang because GCC cross toolchains are miserable) as well as libc headers for your target.

Splitting the crate would be fine though. I assume the "default stores" in the keyring crate would use libdbus?

And would it make sense to yank the v4 prerelease versions, at least the rc? I was tempted to update to it to get ahead of the changes, but that would've been wasted effort if the plan has changed so drastically since that rc.

[brotskydotcom]

Thanks for this comment! It feels to me like confirmation that clients of keyring have lots of different needs and would welcome having complete control over their choice of credential store modules (rather than relying on defaults).

Yes, I have been thinking about yanking the published rc builds because they are, indeed, very misleading. I'm glad to hear an voice outside my head say the same thing :). I have now yanked all the 4.0 builds.