Update identity related fields in protocol move request

[dbanck]

This PR addresses two shortcomings when dealing with identities in the context of cross resource moves.

1. It adds the source_identity_schema_version fields to include all information a provider may need to decode the data
2. It changes the type of the source_identity to make it more clear that it contains the raw identity data

Target Release

1.12.x

CHANGELOG entry

• This change is user-facing and I added a changelog entry.
• This change is not user-facing.

[austinvalle]

Should we be consistent with UpgradeResourceIdentity here and just use bytes?

[jbardin]

Maybe UpgradeResourceIdentity should be consistent with the existing calls and use RawState?

[austinvalle]

Either/or 😆

I actually dropped a comment on the RFC recently about potential "future" data in identity and whether that would potentially be part of these types of RPCs: https://docs.google.com/document/d/1jvNfineZgXaKFP5djLkMxXKf9s6Xq-FzBV3p2jHGbiI/edit?disco=AAABe3pkd1Y

If that seems like something we might do, perhaps a new RawIdentity would fit as well

[dbanck]

Good catch! I'll update it the other way around to be consistent.

The idea there was that if we ever added a new base encoding that wasn't json, it could be added to that message type.

[jbardin]

RawState is just meant to represent raw encoded data from the state file, and not imply any meaning of that data. The encoded identity is just a chunk of the resource's state, with the same encoding as the state in general, hence RawState. In reality RawState was required at the time of the 0.11-0.12 transition because there were multiple state encodings, and it's also been maintained since because however unlikely there could a different encoding in the future. We could decide that all raw state encoded data must be json, but I think that's outside the scope here, and we should use the existing patterns in place until then ;)

[austinvalle]

Fair enough, sounds good to me 👍🏻