`musig::SecretNonce::dangerous_from_bytes()` even more dangerous than documented

[Ademan]

Per the docs in libsecp https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1_musig.h#L28

Opaque data structures

The exact representation of data inside the opaque data structures is implementation defined and not guaranteed to be portable between different platforms or versions.

It would be simple enough to just document this, but I'm not sure if it makes sense to keep the API. It's absolutely a workflow that library consumers want (I want it myself) so maybe that need is strong enough, it just strikes me as a pretty high caliber footgun in addition to the already documented danger.

[apoelstra]

Hmm, yeah, this is a good observation. And upstream does not provide any "serialize"/"deserialize" functions that we can use to get a stable representation.

I'm a little tempted to petition upstream for these methods, but I think they'll say no.

FWIW I think it's extremely unlikely for this particular "opaque data type" to ever change, since its contents consist of 32 totally-unstructured bytes. I suspect they just labeled it "opaque" to discourage us from doing exactly what we've done here.

Probably our best course of action is to just document the risk, as you say.

[Ademan]

As I expected, bark is using dangerous_{into,from}_bytes and even though I have a way to avoid it, I want to use it, too.

I think that means the API should stay, I'll go ahead and cook up a doc update PR.

[Ademan]

Fixed by #805