--dry-run fails with workload create for pre-existing workload and returns full workload object with status rather than just example of what would be created/applied.

[heyjcollins]

WIP

to do:

1. create separate issue for the enhancement, leave create --dry-run error issue as bug
2. spec supported flag values/default
3. update help
4. default = server (start deprecation)
5. deprecation warning
6. consider time-bomb (once deprecation window is up, automatic switch of default , hide warning message, update default in helpoutput)

Please fill out the issue checklist below and provide ALL the requested information.

• I reviewed open and closed Github issues that may be related to my problem.
• I am reporting a bug that others will be able to reproduce.

Describe the bug

2 issues:

1. running tanzu apps workload create/apply appname -f workload.yaml --dry-run for an existing workload should return output the workload object that would be created/applied if the command were to actually run - but currently, the entire object including status is returned -- that's not expected.
2. running tanzu apps workload create appname -f workload.yaml --dry-run for an existing workload throws an error -- but in the case of --dry-run, the intention is to see what changes would be made - but the changes aren't applied
   ** the validation which errors because you can't create something that's already been created is happening here, but when --dry-run is included, that should short-circuit the validation

Expected behavior

issue 1: return output the workload object that would be created/applied
issue 2: return output the workload object that would be created/applied

Steps to Reproduce

issue 1:

1. create a workload named foo
2. run tanzu apps workload create foo --env foo=bar --dry-run
3. returned the full workload object including status rather than just the workload object that would be submitted

issue 2:

1. create a workload named foo
2. run tanzu apps workload create foo --env foo=bar --dry-run
3. error

Screenshots

If applicable, add screenshots to help explain your problem.

Version (Apps plugin version, Version of K8s running on cluster)

apps v0.9.0, but this issue likely goes all the way back to v0.1.0

[shashwathi]

For context, in CLI dry-run is implemented with server side strategy, i.e., object is submitted to the API but not persisted. To allow users to use dry-run without submitting to server, CLI needs to add support for client side strategy.

Proposed solution: Allow users to set client or server for --dry-run flag. This is inspired from kubectl
ref: https://kubernetes.io/blog/2019/01/14/apiserver-dry-run-and-kubectl-diff/#apiserver-dry-run