Reduce cryptography usage in --cfg=fuzzing

[TheBlueMatt]

This reduces the usage of real cryptography in --cfg=fuzzing,
specifically replacing the secret->public key derivation with a
simple copy and ECDH with XOR of the public and private parts
(plus a stream of 1s to make a test pass that expected non-0
output).

It leaves secret tweak addition/multiplication as-is.

It also changes the context creation to over-allocate and store
the context flags at the end of the context buffer, allowing us
to easily test context flags in each function.

While it would be nice to have something fancier (eg XOR-based),
its not immediately obvious how to accomplish this, and better to
fix the issues I have than spend too much time on it.

Fixes #271.

This partially reverts b811ec1

[TheBlueMatt]

Rebased on latest upstream with no changes.

[TheBlueMatt]

Rebased on latest upstream with no changes.

[apoelstra]

ack f1e34bf

lol @ the hand-rolled synchronized static context creation. I believe it's correct, though it took me some time to reason through it.

[apoelstra]

needs rebase now

[TheBlueMatt]

Rebased, was just a super-trivial new test method that was at the same spot as one that is added here.

[apoelstra]

ack 79119e8

[apoelstra]

@TheBlueMatt rust-miniscript fuzz tests are now failing because public keys do not round-trip

[apoelstra]

if you parse

0439033304444444444444444444444444444444444444444444444444444444444444444444444444444444444444444444433333333333333333333323972654

then print it you get

0439033304444444444444444444444444444444444444444444444444444444440003330444444444444444444444444444444444444444444444444444444444

[apoelstra]

(I think this is straightforward to fix, we just need to tighten up the parsing a bit, I can open a PR later today or maybe @sanket1729 can)

[TheBlueMatt]

Grrr sorry about that, I guess I hardly tested full public key parsing instead of just the compressed public keys. Indeed, just storing more info seems like a good solution.

[sanket1729]

I tried to fix this. But I think it is impossible to solve this in the current framework. We use byte 32 in public key to overwrite whether the key was compressed or not.

But when doing this, we lose the corresponding information for uncompressed pubkeys. And we would need a call to libsecp again to construct the y-coordinate which would require moving the parsing functions to not(fuzzing) that might break the goal of the PR.

Looking for more input on this issue. @TheBlueMatt @apoelstra

[sanket1729]

One solution I can think of is to encode 02 compressed keys are x-coordinate``<000......000> and 03 as x-coordinate``<ffff......fffff>. That way, it is improbable that fuzzer would guess these exact values when trying to parse an uncompressed public key.

If the parsers look at the code and then choose the data inputs/control paths, I think this solution will also crash.