channeld: allow remote node to exceed their own HTLC count limits.

We try not to exceed either side, but the spec still allows them to
(we don't, but older nodes would have, as could other implementations).

Fixes: ElementsProject#3953
Changelog-Fixed: protocol: overzealous close when peer sent more HTLCs than they'd told us we could send.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

channeld/full_channel.c

@@ -489,7 +489,6 @@ static enum channel_add_err add_htlc(struct channel *channel,
 	enum side sender = htlc_state_owner(state), recipient = !sender;
 	const struct htlc **committed, **adding, **removing;
 	const struct channel_view *view;
-	u32 min_concurrent_htlcs;
 
 	htlc = tal(tmpctx, struct htlc);
 
@@ -573,16 +572,19 @@ static enum channel_add_err add_htlc(struct channel *channel,
 	 *     HTLCs to its local commitment transaction...
 	 *     - SHOULD fail the channel.
 	 */
-	/* Also we should not add more htlc's than sender or recipient
-	 * configured.  This mitigates attacks in which a peer can force the
-	 * opener of the channel to pay unnecessary onchain fees during a fee
+	if (tal_count(committed) - tal_count(removing) + tal_count(adding)
+	    > channel->config[recipient].max_accepted_htlcs) {
+		return CHANNEL_ERR_TOO_MANY_HTLCS;
+	}
+
+	/* Also *we* should not add more htlc's we configured.  This
+	 * mitigates attacks in which a peer can force the opener of
+	 * the channel to pay unnecessary onchain fees during a fee
 	 * spike with large commitment transactions.
 	 */
-	min_concurrent_htlcs = channel->config[recipient].max_accepted_htlcs;
-	if (min_concurrent_htlcs > channel->config[sender].max_accepted_htlcs)
-		min_concurrent_htlcs = channel->config[sender].max_accepted_htlcs;
-	if (tal_count(committed) - tal_count(removing) + tal_count(adding)
-	    > min_concurrent_htlcs) {
+	if (sender == LOCAL
+	    && tal_count(committed) - tal_count(removing) + tal_count(adding)
+	    > channel->config[LOCAL].max_accepted_htlcs) {
 		return CHANNEL_ERR_TOO_MANY_HTLCS;
 	}