Reduce memory consumption due to proving key

[tromer]

The proving key currently occupies a a large amount of RAM. Let's figure out exactly how much, and evaluate options for reducing this (possibly at some tradeoff with time). The latter include:

• mmapping the key into memory (Consider mmap'ping the proving key into memory #890)
• Just-in-time serialization (and then forgetting) of proving key data
• Avoiding duplicate allocations
• Tighter in-memory representation
• Using EC point compression for in-memory representation

This is in addition, and mostly orthogonal, to changes in the zk-SNARK algorithm (e.g., switching to the Groth'16 construction) or constraints (e.g., hash function).

Related to #416 (on-disk parameter compression).

[tromer]

Also related to #647, "single pour input, value commitment scheme", which would reduce the constraint system size and thus proving key size (to roughly half, if the Merkle hash remains SHA256Compress).

[tromer]

Other potential constraint-system changes that will reduce the proving key size: #40, #2134, #705, #829.

[tromer]

#2171 would reduce the size of the proving key that needs to be loaded into memory at any given execution of the SNARK prover. If the different stages use the same NP statement (see #2171 (comment)) then it would also reduce the total proving key size.

[daira]

This is much better with Sapling, to the extent that I think this ticket can just be closed.