Be more careful about endianness with Identity and Address

[kazimuth]

Description of Changes

This fixes some issues caused by #1616.

We are now more careful about endianness when converting Identity and Address to byte arrays / strings.

API and ABI breaking changes

ABI break; this will require a wipe of modules, since the controldb has been changed to look up identities and addresses by their usual printed form, which corresponds to a big-endian byte array.

Expected complexity level and risk

5/5

Testing

See the added tests, also running smoketests.
I am not sure what else would be a good idea to do.

[kazimuth]

This does not presently fix the incompatibility between the serde and sats serialization of Identity and Address. I will leave that for a later change if needed.

[cloutiertyler]

This is great. Just what the doctor ordered I think. I left a few small comments. Keen to hear about the motivation for changing the control db key serialization.

[cloutiertyler]

This does not presently fix the incompatibility between the serde and sats serialization of Identity and Address. I will leave that for a later change if needed.

Can you be more specific about what incompatibility you mean here?

[kazimuth]

Can you be more specific about what incompatibility you mean here?

Yes, sats+serde_json serializes Identity as {"__identity__": "0x[hex]"} whereas serde+serde_json serializes Identity as merely "[hex]".

This is slightly silly because we already have the IdentityForUrl type in client-api that is defined to serialize as "[hex]".

[kazimuth]

On reflection I don't think this needs anything else, besides possibly additional testing, but I'm not sure what that testing would entail.

[kazimuth]

Okay, I think I've got everything and this is ready.

[cloutiertyler]

This LGTM but internal tests are failing.