add moving with_default_namespace Client setter - fixes #543

[clux]

Follow up to #534 after custom client support in #540.

• add moving Client::with_default_namespace setter
• require default_namespace as an Into<String> arg in Client::new
• update custom_client* examples to use default namespaces on pods (which are more likely to exist in default)
• rename Config::default_ns to Config::default_namespace
• remove Client::new_with_default_namespace alloc)

[kazk]

Yeah, I forgot about this. with_default_namespace setter works, but still allows users to create custom client with incorrect default namespace accidentally. We can prevent that if we make default namespace required for custom client.

I don't think this is bad:

let config = Config::infer().await?;
let https = config.native_tls_https_connector()?;
let client = Client::new(
    ServiceBuilder::new()
        .layer(config.base_uri_layer())
        .option_layer(config.auth_layer()?)
        .service(hyper::Client::builder().build(https)),
    config.default_namespace,
);

It's a breaking change, but this is not widely used yet and the fix is trivial.

[clux]

with_default_namespace setter works, but still allows users to create custom client with incorrect default namespace accidentally.

Yeah, that is true. But it's also possible that the user is just puts "default" there anyway. We don't really have full safety here either way. If we had more properties required (like extensions), we could have put Config as the argument:

let client = Client::new(service).with_defaults(config);
let client = Client::new(service, config);

but right now that's even more wasteful allocation-wise.

Probably thinking about this for more than I should. The explicit Into<String> arg is probably likely to catch most errors, while being the least bad. It's not like we could do impl From<Service> for Client where ALL_THE_CONSTRAITS in a nice way anyway.

I'll tweak the PR tomorrownow.

[kazk]

But it's also possible that the user is just puts "default" there anyway. We don't really have full safety here either way.

Yeah, my point was "forgetting" about this setter. If the default namespace was a parameter, then it's impossible to forget. I'm hoping Service stack will be flexible enough, and we don't need to add any more parameters.

[clux]

Yeah, I think that's the right trade-off as well now. PR updated.
(See there's a bunch of unrelated new clippy things, but will do those separately)