Ensure proper memory clean-up for secret in libsecp256k1 dependency.

[Slesarew]

Two other upstream crypto libraries are using zeroize to clear memory used for storing secrets (see https://docs.rs/ed25519-dalek/1.0.1/src/ed25519_dalek/secret.rs.html#43 and https://docs.rs/schnorrkel/0.9.1/src/schnorrkel/keys.rs.html#680), but libsecp256k1 apparently does not. This will normally not be a severe issue in substrate as this algorithm is not used much, but it might cause all secrets to memory leak in the Signer, which depends on sp-core and uses all 3 crypto algorithms to maximize future compatibility.

As discussed with @kirushik and @burdges in PM, so tagging them here as well.

[Slesarew]

@kirushik we might want to wrap this crypto object in zeroize here depending on whether it would be wrapped upstream; not as good though, I understand.

We could forbid use of that lib in Signer temporarily as temporary workaround; not sure if it is worth it though - we'll lose this crypto type then obviously.

[kirushik]

@Slesarew since doing a better job at maintaining our libsecp fork is something we'd want to do anyway, looping Thomas in here — the linked paritytech/libsecp256k1#93 issue might be a good starting point for the new libsecp co-maintainer.

Please just use the library "as is" in Signer — and make a note to check that this issue is fixed before moving Signer anywhere near a public beta.

[Slesarew]

and make a note to check that this issue is fixed before moving Signer anywhere near a public beta.

Oh ok, so I'm moving this deadline from private to public beta, that's a relief

[bkchr]

since doing a better job at maintaining our libsecp fork is something we'd want to do anyway

FWIW: #8089 we will switch away from our own fork in the future.