encode: add some more generic impls (more tuples, references)

[apoelstra]

No description provided.

[sgeisler]

Do you want to fix the breakage caused by byteorder changing its MSRV here or in a separate PR? I already have a commit that does that 9657048 but didn't want to push it here. There is a high chance that it'll need a god-mode merge for being a CI change 😕

[apoelstra]

Thanks! I'll just cherry-pick your commit here.

It shouldn't need a god-mode merge, for what it's worth. Only enabling GA for the first time did.

[sgeisler]

It shouldn't need a god-mode merge, for what it's worth

It really should in a secure system: I could change the CI code such that it reveals CI secrets, so it's not safe to run the PRed CI code until it is merged. But I guess it will work due to the indirection with the bash script. CI security is a mess.

[apoelstra]

I mean, there are options I can enable that'd make it impossible for outsiders to change CI. But I haven't enabled them.

[sgeisler]

ACK ef116ff

Thinking about it a bit more you could probably also get away with implementing Encodable for T: AsRef<E> where E: Encodable to support all kinds of smart pointers, but the current version is much more transparent.

[apoelstra]

@sgeisler no, we specifically avoid &[u8], even though it would be useful, because @TheBlueMatt complained that arrays sometimes coerced to it, causing them to be length-prefixed when arrays normally are not.

[apoelstra]

Actually, I think T: AsRef<E> wouldn't cover &[u8] ... but I'm not sure what it does cover, so agree that it's best to be more transparent.

[sgeisler]

It would, but I had to look it up too 😆

[sanket1729]

tACK ef116ff

[sanket1729]

re tACK ef116ff