feat(normalisation): jsonNormalisation/v3 and fixes to jsonNormalisation/v1 as well as jsonNormalisation/v2

[jakobmoellerdev]

What this PR does / why we need it

Package jsonv3 provides a normalization which is completely based on the abstract (internal) version of the component descriptor and is therefore agnostic of the final serialization format. Signatures using this algorithm can be transferred among different schema versions, as long as is able to handle the complete information using for the normalization. jsonv2 is the predecessor of this version but had internal defaulting logic that is no longer included as part of this normalization. Thus v3 should be preferred over v2. Note that between v2 and v3 differences can occur mainly if the "extra identity" field is not unique, in which case the v2 normalization opinionated on how to differentiate these items. This no longer happens in v3, meaning the component descriptor is normalized as is.

v2 and v1 were adjusted to accomodate the old(but new because forgotten) legacy behavior in legacy.go. Without this, old signatures would not work. This means this should be (at least partially) back-ported to the last minor versioned released without this correction.

Which issue(s) this PR fixes

This issue fixes #1214 and supercedes #1217 as a better solution longterm (by getting rid of the old normalization) and shortterm (by achieving full backwards compatibility + introducing a simple test case)

Note that this changes the default normalization algorithm to be jsonNormalisation/v3 instead of jsonNormalisation/v1 as it is important for users to migrate as soon as possible.

[Skarlso]

One question, otherwise, lovely job Jakob! :)

[mandelsoft]

I'm not sure, why you created a new normalization v3, which is basically exactly the same as v2, before, and changed v2 to modify the component descriptor.

Normalization should never change anything.

The issue stated, that the problem arises after a transport, therefore it cannot be caused by the normalization, but by the transport handling of the extra identity (as you correctly identified in your comment in the issue).

So, it is caused by the defaulting done in the SetResource and SetSource methods of a CV. If modify mode is on, it defaults the extra identity according to the new rules.
This has been intended for the creation of a component version, but this should never happen during a transport.

Therefore, we have to fix the transport behavior, ere. This is only possible by introducing a new modification option for those methods, which instruct the adding to keep the original method data and do not the defaulting. The transport tool then has to give this option. (see #1223)

[jakobmoellerdev]

I'm not sure, why you created a new normalization v3, which is basically exactly the same as v2, before, and changed v2 to modify the component descriptor.

Normalization should never change anything.

I changed it because your change broke existing logic for normalization. Before, it didnt matter if the component versions contained extra identities or not, now it does. V3 simply makes this break obvious.

The issue stated, that the problem arises after a transport, therefore it cannot be caused by the normalization, but by the transport handling of the extra identity (as you correctly identified in your comment in the issue).

So, it is caused by the defaulting done in the SetResource and SetSource methods of a CV. If modify mode is on, it defaults the extra identity according to the new rules. This has been intended for the creation of a component version, but this should never happen during a transport.

This is true, but at the same time, the normalization is not allowed to change. I still think the change you submitted is relevant, but the normalization must stay the same.

Therefore, we have to fix the transport behavior, ere. This is only possible by introducing a new modification option for those methods, which instruct the adding to keep the original method data and do not the defaulting. The transport tool then has to give this option. (see #1223)

Also true, but existing (already transferred) component versions have to be verifiable as well, even with the transport having changed the extra identity