Fully static precomputation tables

[real-or-random]

Currently we offer secp256k1_context_no_precomp [1] but it's a "none" context.

If static precomputation (for ecmult_gen contexts) is enabled, we could easily offer a static secp256k1_context_sign. I believe we should do this and additionally offer static precomputation for ecmult contexts. This will make it possible to offer a static secp256k1_context_verify and a fully static secp256k1_context_sign_verify depending on the compilation flags.

I think this is very helpful for embedded targets and is probably much more convenient to use than the prealloc API [2], which requires to users to obtain the size of the context secp256k1_context_preallocated_size() at runtime and deal with manual allocation etc.

[1] Note that the docs can be improved here. They describe the context in terms of internals ("precomputed tables"). We should also describe this in terms of equivalent context flags. The same is true for the name of this thing.

secp256k1/include/secp256k1.h

Lines 186 to 191 in 8c727b9

	/** A simple secp256k1 context object with no precomputed tables. These are useful for
	* type serialization/parsing functions which require a context object to maintain
	* API consistency, but currently do not require expensive precomputations or dynamic
	* allocations.
	*/
	SECP256K1_API extern const secp256k1_context *secp256k1_context_no_precomp;

[2] Also with behind language bindings #892, see also @gmaxwell's comment there advocating for a fully static context

[real-or-random]

Fully static contexts would lose any ability to do randomization. The cost of creating a context that has a few bytes in it is extremely low-- the thing that really ought to be static is the tables, everything else is quite cheap.

Indeed, I totally forgot about randomization. If we had static ecmult_gen tables and static ecmult tables, I think we can still make it easier for users to create contexts.

Some operations-- e.g. batch operations -- will always need scratch memory too.

Right but I don't think they will need to belong to the context, and not everyone will need them.

I did not intend to advocate making the context some static variable-- just making the expensive to compute tables static.

Yeah sorry, I noticed it when I read your comment again and should have edited my post here.

If a fully static context can be used then what is the point of having any context at all? -- if it's actually possible to eliminate the context it's probably better to do that.

Hm, I guess not everyone has the same tradeoffs (code size, etc.), so if we get rid of contexts, we'll lose some flexibility.

[real-or-random]

Related comment: #918 (comment)