Allow duplicate-payment_hash HTLCs for HTLC forwards

This is required by BOLT 2 to ensure that no attacker can simply
relay every public node a duplicate-payment_hash HTLC for each HTLC
it receives to deduce where an HTLC came from.

Note that this makes the claim logic much less incentive-compatible
as we will not claim all available HTLCs with the same payment_hash
even if we know the preimage! This is OK because, most likely, any
attackers trying to map the network will use small-value payments
and, hopefully, we will move away from constant hashes across an
entire payment at some point in the near future.

This further simplifies the payment transition state a bit, so
hopefully at least we got some readability out of all of this

Author: TheBlueMatt

fuzz/fuzz_targets/channel_target.rs

@@ -8,7 +8,7 @@ use bitcoin::util::hash::Sha256dHash;
 use bitcoin::network::serialize::{serialize, BitcoinHash};
 
 use lightning::ln::channel::{Channel, ChannelKeys};
-use lightning::ln::channelmanager::{HTLCFailReason, PendingHTLCStatus};
+use lightning::ln::channelmanager::{HTLCFailReason, HTLCSource, PendingHTLCStatus};
 use lightning::ln::msgs;
 use lightning::ln::msgs::{MsgDecodable, ErrorAction};
 use lightning::chain::chaininterface::{FeeEstimator, ConfirmationTarget};
@@ -269,7 +269,7 @@ pub fn do_test(data: &[u8]) {
 	loop {
 		match get_slice!(1)[0] {
 			0 => {
-				test_err!(channel.send_htlc(slice_to_be64(get_slice!(8)), [42; 32], slice_to_be32(get_slice!(4)), msgs::OnionPacket {
+				test_err!(channel.send_htlc(slice_to_be64(get_slice!(8)), [42; 32], slice_to_be32(get_slice!(4)), HTLCSource::dummy(), msgs::OnionPacket {
 					version: get_slice!(1)[0],
 					public_key: PublicKey::from_slice(&secp_ctx, get_slice!(33)),
 					hop_data: [0; 20*65],