chaintopology: better feerate targets differentiation

We kept track of an URGENT, a NORMAL, and a SLOW feerate. They were used
for opening (NORMAL), mutual (NORMAL), UNILATERAL (URGENT) transactions
as well as minimum and maximum estimations, and onchain resolution.

We now keep track of more fine-grained feerates:
- `opening` used for funding and also misc transactions
- `mutual_close` used for the mutual close transaction
- `unilateral_close` used for unilateral close (commitment transactions)
- `delayed_to_us` used for resolving our output from our unilateral close
- `htlc_resolution` used for resolving onchain HTLCs
- `penalty` used for resolving revoked transactions

We don't modify our requests to our Bitcoin backend, as the next commit
will batch them !

Changelog-deprecated: The "urgent", "slow", and "normal" field of the `feerates` command are now deprecated.
Changelog-added: The fields "opening", "mutual_close", "unilateral_close", "delayed_to_us", "htlc_resolution" and "penalty" have been added to the `feerates` command.

lightningd/json.c

@@ -115,6 +115,15 @@ struct command_result *param_feerate(struct command *cmd, const char *name,
 		if (json_tok_streq(buffer, tok, feerate_name(i)))
 			return param_feerate_estimate(cmd, feerate, i);
 	}
+	/* We used SLOW, NORMAL, and URGENT as feerate targets previously,
+	 * and many commands rely on this syntax now.
+	 * It's also really more natural for an user interface. */
+	if (json_tok_streq(buffer, tok, "slow"))
+		return param_feerate_estimate(cmd, feerate, FEERATE_MIN);
+	else if (json_tok_streq(buffer, tok, "normal"))
+		return param_feerate_estimate(cmd, feerate, FEERATE_OPENING);
+	else if (json_tok_streq(buffer, tok, "urgent"))
+		return param_feerate_estimate(cmd, feerate, FEERATE_UNILATERAL_CLOSE);
 
 	/* We have to split the number and suffix. */
 	suffix.start = suffix.end;