API BREAKAGE: add a lows flag to secp256k1_ecdsa_sign #69

Not sure if tests are necessary here. I've probably oversimplified, but this was enough to get bitcoin's tests passing again with libsecp256k1.

What? I don't think this should be a flag. What test is failing?

<coryfields_> sipa: i've fixed up the libsecp256k1 in bitcoin (testing it in libbitcoinconsensus), and it's having trouble with a particular test. Known issue for "P2PK with high S" ?
<sipa> coryfields_: that sounds very expected
<coryfields_> ok, will just skip over it
<sipa> it needs a change in secp256k1's api, i'm afraid
<sipa> as you can't tell it to not use low-S
<coryfields_> figured as much, specifying high/low S i suppose
<coryfields_> ?
<coryfields_> right
<sipa> yup
<coryfields_> want me to take a crack at it? or is it waiting on something?
<sipa> it's trivial to do, you can if you want to

By "trivial" + api change, I assumed he was just referring to a flag similar to the one our openssl wrapper uses.

okay if sipa says so! seems odd to introduce an call just to get that behavior.

Not sure if this is actually what he was after or not, it was just the most trivial way I could come up with.

I suppose for a bit of future-proofing we could use a bitfield param instead, where lowS is the only valid flag for now.

@theuni This is indeed exactly what I meant. @gmaxwell It's only needed for unit tests, to be able to generate cases with longer S values. Alternatively, it could be implemented by having parse/serialize/subtraction bignum functionality in the unit tests.

I've implemented a replacement on the bitcoin side: bitcoin/bitcoin@4a69b3b0174014e611143c31d411dde9d377aa98

Closing in favor of bitcoin/bitcoin#5256.