Merge host component key value implementations into new factor crates

[calebschoepp]

No description provided.

[rylev]

Looks good! Thanks.

I left a few comments about submodule naming. Relatedly, I do wonder if using the word "factor" in the various implementation crates is correct (e.g., factor-key-value-azure). Now that everything is factor based, I'd personally prefer to keep only crates where the Factor trait is implemented with the name "factor". Everything else should drop "factor":

• factor-key-value-azure => key-value-azure
• factor-key-value-spin => key-value-spin or key-value-sqlite
• factor-key-value-redis => key-value-redis

I feel somewhat strongly that this naming scheme is better, so I'd like to block merging just to make sure we have this conversation. However, if others feel differently, I have no issue quickly switching to approve this PR. cc @lann

[lann]

submodule naming

I'm on the fence with this one.

From a bottom-up perspective I get the point about the "factors" label not really applying to e.g. individual KV impls. You could even imagine consuming the Store/StoreManager traits from non-factors code.

However, from a top-down organizational perspective it seems like it might be less confusing - especially to unfamiliar readers - if everything KV-related is under the same spin-factors-key-value-* "namespace".

[calebschoepp]

FWIW I prefer Ryan's suggestion of dropping the factor- prefix. If I were walking into this codebase with fresh eyes I would find it confusing why there are crates with factor- prefixes that aren't actually factors. To me it becomes more clear that these KV crates are dependencies when we remove the factor- prefix. @lann are you happy with me going ahead in this direction?

[calebschoepp]

I think I've addressed all the requested changes and this is ready for a re-review.

[calebschoepp]

I don't have permissions to merge so it'd be great if you could do it @rylev or @lann.