Explicitly convert inMediaType json to outMediaType yaml

[Deathstr0ke1]

CRDs currently can be read with --output=json and that is generally how it is encoded in k8s as well. I think there are discussions regarding other encoders for CRDs. Until that changes, we do not really need to worry about that. However we do need to add better documentation of how to decode CRDs.

Since you mentioned in #33 that CRDs can be read using --output=json, I believe this indicates that auger is functionally capable of correctly accessing data in the application/json format (similarly for other data types like CRDs which are also in application/json format). Therefore, I think that when attempting to read this data without the --output=json parameter, the output error decoding from application/json: xxxx is an unfriendly of program logic, because this data can indeed be accessed normally and should not throw an error.
I modified the logic in encoding.go so that when inMediaType is json and outMediaType is yaml(the default case), it explicitly converts the json data to yaml format for output.

[Deathstr0ke1]

I ran some local tests to see if this works for CRDs, storing data in JSON format, such as /registry/apiregistration.k8s.io/apiservices/v1., /registry/cilium.io/ciliumidentities/xxx.
BTW, I believe that since under the original logic:

try to decode any CRDs storing data in JSON format in default case output=yaml would throw errors

the logic of this PR will still correctly display the rare cases where certain CRDs cannot be decoded from JSON to YAML due to decoding issues. It simply optimizes the user interaction for decoding 'regular CRDs'.

Therefore, I think there's no need to do extensive testing. What do you think? @siyuanfoundation

[wzshiming]

😄 I think we can just use yaml.YAMLToJSON and yaml.JSONToYAML from sigs.k8s.io/yaml

I made a similar change in another repo.
https://github.com/kubernetes-sigs/kwok/blob/a284d0ca8703257a9b36a48bb4de328898268162/pkg/kwokctl/etcd/etcd.go#L61-L75

[Deathstr0ke1]

You're right about this.

[siyuanfoundation]

I ran some local tests to see if this works for CRDs, storing data in JSON format, such as /registry/apiregistration.k8s.io/apiservices/v1., /registry/cilium.io/ciliumidentities/xxx. BTW, I believe that since under the original logic:

try to decode any CRDs storing data in JSON format in default case output=yaml would throw errors

the logic of this PR will still correctly display the rare cases where certain CRDs cannot be decoded from JSON to YAML due to decoding issues. It simply optimizes the user interaction for decoding 'regular CRDs'.

Therefore, I think there's no need to do extensive testing. What do you think? @siyuanfoundation

It is fair to say that we do not have to cover all the corner cases.
We do need to add more unit tests for this package. But that can be a followup.

Can you rebase and make sure the tests are green?

[Deathstr0ke1]

I forgot that the previous PR changed the number of return values, it has now been fixed.

[siyuanfoundation]

/cc @jmhbnz

[jmhbnz]

LGTM - Thanks @Deathstr0ke1