feat: readable linking challenge

[weichweich]

fixes /~https://github.com/KILTprotocol/ticket/issues/2499

Replace the scale encoded challenge with a human readable challenge.

Checklist:

• I have verified that the code works
  • No panics! (checked arithmetic ops, no indexing array[3] use get(3), ...)
• I have verified that the code is easy to understand
  • If not, I have left a well-balanced amount of inline comments
• I have left the code in a better state
• I have documented the changes (where applicable)

[trusch]

lgtm :) Will look nice in the display of metamask. The only thing even better would be probably something like giving MM a typed struct with the info so it could render it even nicer. https://docs.metamask.io/guide/signing-data.html#signtypeddata-v4

[weichweich]

lgtm :) Will look nice in the display of metamask. The only thing even better would be probably something like giving MM a typed struct with the info so it could render it even nicer. https://docs.metamask.io/guide/signing-data.html#signtypeddata-v4

Yeah that would be nice, but it's only for ethereum. So we would have a special challenge for ethereum which is also possible. But i think this just makes it more complicated for little gain. It will also not get easier to process on chain.

[ntn-x2]

So while before we were attempting to have a future-compatible SDK, now we will force all people to upgrade to the new version, otherwise stuff will break. Correct?

[ntn-x2]

I have never seen it used anywhere else. Are you sure there's no other way to do this? Perhaps feature-gating the specific tests or the mock itself?

[weichweich]

We always run tests with at least the std feature. I also want to test get_challenge in a no_std environment since debug might be implemented differently there (e.g. for accounts it simply prints nothing).

To be able to test this without std I need to disable all tests that require std.

[weichweich]

So while before we were attempting to have a future-compatible SDK, now we will force all people to upgrade to the new version, otherwise stuff will break. Correct?

Things break because the SDK doesn't include these surprise changes yes.

[ntn-x2]

@weichweich do you think it would make sense to expose the new stuff as a new extrinsic? So the old SDK would still work without breaking, and the new SDK would use the new feature. I mean both extrinsics would support Ethereum accounts, but the type of signature would be different. We can then deprecate the old way later on.

I guess my main concern is that people can't just decide not to upgrade, since the old linking stuff would break as well.