Remove kube Dependency in kube-derive

[kflansburg]

Closes #516

This gives an idea of how the kube dependency can be removed. A few sharp edges still:

• We can only reference one path in the derive macro, so they either have to always add kube or always add kube-core to their Cargo manifest.
• I'm sure there are CI changes that need to be made due to the new crate.

I've also taken the liberty of fixing some Clippy lints that were preventing compilation (in a separate commit).

[clux]

Hey, thanks a lot for doing this. I was thinking something like this might be helpful for breaking dependencies, but was never sure what it was going to benefit directly.

Fundamentally, I have no qualms with doing this, looks like we can do this in ways that don't break anything and have kube re-export from kube-core. Although, it will probably be a bit of duelling with tests before it's all good. I'm here to help.

[clux]

Note to self: the version keys need to be in there to avoid cyclic dependencies in publishing, but maybe the first release needs to be special cased.

[kflansburg]

Great, I will address your comment and take a pass at fixing the tests in a bit.

[clux]

There's potentially three more things we could include in this crate. Like the part of the api bindings that doesn't use hyper, I'm thinking:

• ResourceExt trait (mentioned before)
• api/params.rs
• api/request.rs (does not use a client lib)

That way we have a more cohesive story for the non-tokio/non-client wanting crowd.

[kflansburg]

Ok, I moved the things you mentioned. Moving params.rs involved redefining a few Error variants, and moving Request involved splitting subresource.rs across the two crates.

I ran most of the tests locally, will see if it passes on Circle.

[clux]

oh, this isn't ideal, we can't select this feature for users

[clux]

it's possible that the implementations of Resource and ResourceExt needs to be in kube to avoid having this feature issue here.

[kflansburg]

Hmmm, that's unfortunate because that's the type that is causing issues for me.

This only caused problems for running the tests, so maybe we can just specify the feature in CI?

[kflansburg]

I've made this change if that works for you.

[clux]

Ah, yeah, that works. The standard pattern we have is to select the feature* internally:

[dependencies.k8s-openapi]
version = "0.11.0"
default-features = false
features = []
[dev-dependencies.k8s-openapi]
version = "0.11.0"
default-features = false
features = ["v1_20"]

[clux]

I'll merge this and play around a bit with it in master. Don't see anything obvious here, and CI is passing. Maybe this is just a quick release :-)

[clux]

Ended up moving a bunch more core types in there into kube-core in #519 without adding any deps.

[clux]

Released with modifications in 0.54.0 (#522 additional imports). Thanks again!