context: prevent clones from copying allocator residue #1913

Problem: Context creation initializes every member but leaves padding bytes untouched. Cloning a dynamically allocated context into caller-provided storage may copy undefined allocator bytes with the other members. The caller remains responsible for that storage after destroying the context, so memory checkers report the undefined bytes when the block is compared or written out. This is a local initialization defect, no remote or Bitcoin Core path is known.

Fix: Zero the complete context representation before member initialization and clone assignment. Extend the existing context test to require every byte to be defined after both creation modes and both clone modes.

It's unclear to me if this is a problem in the first place, as users are not meant to inspect the raw bytes of context objects (or any other opaque objects for that matter), so the mentioned "block is compared or written out" scenario which would presumably trigger a report by memory checkers seems one that is outside of the API contract. After destroying the context, that contract arguably ends, but I can't see why users would want to perform any reads from the memory either before freeing (I'd imagine they just do nothing if it's stack/global storage, or calling a free equivalent if it was dynamically allocated by the user), so it seems a bit far-fetched. If we are really worried about that latter scenario, maybe do the memset only at the end of secp256k1_context_preallocated_destroy, and leave the other functions unchanged? Curious what other reviewers think.

During the lifetime of a context object, uninitialized padding bytes seem to be just fine in any case.

Thank you, closing, if other reviewers disagree we can reopen