feature: make rustls default in fluvio, move to reqwest from surf

[ozgrakkurt]

• Made rustls feature on fluvio the default
• Made most components use rustls if it is enabled. It used to use openssl anyway because of a compatibility problem.
• Removed usage of surf because it is not maintained and added reqwest instead.

closes #3091
closes #3113
closes #3070

Seems like a bunch of things need to be manually checked using the cli before we are sure this works?. One problem might be that we need async-std/tokio1 enabled and I enabled it in fluvio crate but this will be problem if the sub-crates are used somewhere else where async-std/tokio1 isn't enabled.

[ozgrakkurt]

@digikata it isn't possible to get rid of openssl entirely for now because we depend on cargo-generate which doesn't seem to give an option to use rustls or run without tls.

[ozgrakkurt]

"solved" the issue with async-std/tokio01 by just adding it as a dep to every crate we use reqwest

[ozgrakkurt]

@sehz. I moved features from workspace to individual crates, made everything use rustls as much as I can and the rest uses openssl/native-tls.

removed tls features on fluvio crate.

[ozgrakkurt]

seems like there are errors about doing fluvio-future = { workspace = true }, how should I handle these? Do we need the version to be specified in each of these crates?

[sehz]

you don't need to specify version but need specific feature enabled in each crate that need optional features

[ozgrakkurt]

@sehz bumped versions also fixed some mistakes. Also this is a breaking change since I removed the openssl and rustls features from fluvio crate

[digikata]

Looks really good so far, after it settles down more I wonder if it might be worth splitting apart the PR to some boundaries to phase it in. It's a large number of changes, so separating possible side effects to smaller sets of changes makes it easier on downstream projects like fluvio-cloud-ops. e.g. the fluvio-future syncup to a workspace dep might be worth peeling off and merging to master before this.

[ozgrakkurt]

Looks really good so far, after it settles down more I wonder if it might be worth splitting apart the PR to some boundaries to phase it in. It's a large number of changes, so separating possible side effects to smaller sets of changes makes it easier on downstream projects like fluvio-cloud-ops. e.g. the fluvio-future syncup to a workspace dep might be worth peeling off and merging to master before this.

Makes sense, probably gonna have to do this like reqwest change and then another PR for the TLS. My bad on this PR

[digikata]

Makes sense, probably gonna have to do this like reqwest change and then another PR for the TLS. My bad on this PR

No worries, the exploratory work had to be done to find out what the extent of the changes might be. Pretty normal to do the exploration then take a step back and reasses the change sets.

[github-actions]

Stale pull request message