CAP-64: Modify XDR field ordering in SorobanAddressCredentialsV2

[Shaptic]

I'm not sure if this was intentional or not but I think it's a mistake since it doesn't match the later section which has the memo last. This will increase binary compatibility across the two credential types.

[dmkozh]

These are binary incompatible anyways, so I don't see any value in one struct being a subset of another one. However, I think it might make more sense logically to put this after signatureExpirationLedger. I think signature should still go last in order to better group the fields logically (payload, then signature).

[Shaptic]

True that they're strictly incompatible, but one could feasibly just append a int32 = 0 to the end of a V1 bytearray to get a valid V2 which could be nice 🤷

The issue still stands of the later +case ENVELOPE_TYPE_SOROBAN_AUTHORIZATION_V2: structure in the XDR diff not matching the SorobanAddressCredentialsV2 one - regardless of which order is best, they should match, right?

[dmkozh]

but one could feasibly just append a int32 = 0 to the end of a V1 bytearray to get a valid V2

Sure, one could, but the question is whether one should, and I don't think they should. I would prefer people using the XDR wrappers instead of modifying the binary structure directly.

structure in the XDR diff not matching the SorobanAddressCredentialsV2 one - regardless of which order is best, they should match, right?

These can't match because the credentials only contain a subset of fields to be signed. But I think we can match the relative order of the matching fields; which is why I suggested moving memo after signature expiration (and probably we should do that in the envelope as well then).

[Shaptic]

Gotcha, yeah agreed on all counts. I'll close this then and let you unify relative orders to be consistent how you see fit 👍