Minimize split packages across api and client modules

[shawkins]

Is your task related to a problem? Please describe

The split with #3654 left packages in both the api and client side.

kubenetes:
client
dsl.base
extended.run
informers
informers.cache
utils

openshift:
client

Describe the solution you'd like

With the exception of the client packages (DefaultKubernetesClient/DefaultOpenShiftClient), there is nothing in the other packages that users should have been directly referencing. We should feel free to repackage the classes in whatever way makes sense - if there is already a related one, or add an internal package, etc. That applies to the remaining classes (mostly *Client and *Adapter) in the implementation client packages as well.

Changing the package on the api side would be a breaking change, but could be considered for the api's dsl.base - those classes could be moved to dsl.

Describe alternatives you've considered

No response

Additional context

No response

[shawkins]

@manusa @rohanKanojia and others, do you have any thoughts here before I put together a pr?

[manusa]

do you have any thoughts here before I put together a pr?

Not really, I think this requires a case per case analysis.

For the extended.run I understand that this is due to the PodOperationsImpl requirement. I guess we could pass an instance of the KubernetesClient to the Impl and this wouldn't be necessary ---> kubernetesClient.pods()...create(convertRunConfigIntoPod())

For most of the others, I think it's just a case of rearranging stuff. I see many classes in both modules that could belong elsewhere.

[manusa]

Should be closed in scope of #3844?

[shawkins]

Yes, we'll capture something related to this once #3865 is resolved - that is once the Default client classes are deprecated, we can move the -client client classes in a subsequent release.

[shawkins]

Addressed with #3844