onion_message: don't use general secret, use per-message secret.

We had a scheme where lightningd itself would put a per-node secret in
the blinded path, then we'd tell the caller when it was used.  Then it
simply checks the alias to determine if the correct path was used.

But this doesn't work when we start to offer multiple blinded paths.
So go for a far simpler scheme, where the secret is generated (and
stored) by the caller, and hand it back to them.

We keep the split "with secret" or "without secret" API, since I'm
sure callers who don't care about the secret won't check that it
doesn't exist!  And without that, someone can use a blinded path for a
different message and get a response which may reveal the node.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

plugins/offers.c

@@ -127,7 +127,7 @@ static struct command_result *onion_message_modern_call(struct command *cmd,
 
 static const struct plugin_hook hooks[] = {
 	{
-		"onion_message_blinded",
+		"onion_message_recv",
 		onion_message_modern_call
 	},
 };