Don't bother clone'ing a Secp256k1 context into the offers flow

The new `OffersMessageFlow` stores yet another `Secp256k1` context
internally, but to initialize requires passing one in explicitly.
We call this in `ChannelManager` by `clone`ing the context we have
before passing it in, allowing us to keep the randomization we do
in `ChannelManager::new`.

This isn't really worth the API annoyance of passing in a
`Secp256k1` context, though, and luckily the contexts are
eventually going to go away upstream eventually, so we just drop
the argument from `OffersMessageFlow::new`, building an
unrandomized `Secp256k1` context internally instead.

Author: TheBlueMatt

lightning/src/ln/channelmanager.rs

@@ -3962,7 +3962,7 @@ where
 		let flow = OffersMessageFlow::new(
 			ChainHash::using_genesis_block(params.network), params.best_block,
 			our_network_pubkey, current_timestamp, expanded_inbound_key,
-			node_signer.get_receive_auth_key(), secp_ctx.clone(), message_router, logger.clone(),
+			node_signer.get_receive_auth_key(), message_router, logger.clone(),
 		);
 
 		ChannelManager {
@@ -17997,7 +17997,6 @@ where
 			highest_seen_timestamp,
 			expanded_inbound_key,
 			args.node_signer.get_receive_auth_key(),
-			secp_ctx.clone(),
 			args.message_router,
 			args.logger.clone(),
 		)

lightning/src/offers/flow.rs

@@ -118,7 +118,7 @@ where
 	pub fn new(
 		chain_hash: ChainHash, best_block: BestBlock, our_network_pubkey: PublicKey,
 		current_timestamp: u32, inbound_payment_key: inbound_payment::ExpandedKey,
-		receive_auth_key: ReceiveAuthKey, secp_ctx: Secp256k1<secp256k1::All>, message_router: MR,
+		receive_auth_key: ReceiveAuthKey, message_router: MR,
 		logger: L,
 	) -> Self {
 		Self {
@@ -131,7 +131,7 @@ where
 
 			receive_auth_key,
 
-			secp_ctx,
+			secp_ctx: Secp256k1::new(),
 			message_router,
 
 			pending_offers_messages: Mutex::new(Vec::new()),