Use ChannelMonitorUpdates in commitment signing fns in Channel

This is a rather big step towards using the new ChannelMonitorUpdate
flow, using it in the various commitment signing and commitment
update message processing functions in Channel. Becase they all
often call each other, they all have to be updated as a group,
resulting in the somewhat large diff in this commit.

In order to keep the update_ids monotonic for ease of use on the
user end, we have to play some games with the
latest_monitor_update_id field, though its generally still pretty
readable, and the pattern of "get an update_id at the start, and
use the one we got at the start when returning, irrespective of
what other calls into the Channel during that time did" is
relatively straightforward.

Author: TheBlueMatt

lightning/src/ln/chanmon_update_fail_tests.rs

@@ -200,6 +200,7 @@ fn do_test_monitor_temporary_update_fail(disconnect_count: usize) {
 				}
 
 				nodes[0].node.handle_commitment_signed(&nodes[1].node.get_our_node_id(), commitment_signed);
+				check_added_monitors!(nodes[0], 1);
 				assert!(nodes[0].node.get_and_clear_pending_msg_events().is_empty());
 				nodes[0].logger.assert_log("lightning::ln::channelmanager".to_string(), "Previous monitor update failure prevented generation of RAA".to_string(), 1);
 			}
@@ -788,6 +789,7 @@ fn do_test_monitor_update_fail_raa(test_ignore_second_cs: bool) {
 		send_event = SendEvent::from_event(nodes[2].node.get_and_clear_pending_msg_events().remove(0));
 		nodes[1].node.handle_update_add_htlc(&nodes[2].node.get_our_node_id(), &send_event.msgs[0]);
 		nodes[1].node.handle_commitment_signed(&nodes[2].node.get_our_node_id(), &send_event.commitment_msg);
+		check_added_monitors!(nodes[1], 1);
 		assert!(nodes[1].node.get_and_clear_pending_msg_events().is_empty());
 		nodes[1].logger.assert_log("lightning::ln::channelmanager".to_string(), "Previous monitor update failure prevented generation of RAA".to_string(), 1);
 		assert!(nodes[1].node.get_and_clear_pending_msg_events().is_empty());
@@ -1171,6 +1173,7 @@ fn claim_while_disconnected_monitor_update_fail() {
 	let as_updates = get_htlc_update_msgs!(nodes[0], nodes[1].node.get_our_node_id());
 	nodes[1].node.handle_update_add_htlc(&nodes[0].node.get_our_node_id(), &as_updates.update_add_htlcs[0]);
 	nodes[1].node.handle_commitment_signed(&nodes[0].node.get_our_node_id(), &as_updates.commitment_signed);
+	check_added_monitors!(nodes[1], 1);
 	assert!(nodes[1].node.get_and_clear_pending_msg_events().is_empty());
 	nodes[1].logger.assert_log("lightning::ln::channelmanager".to_string(), "Previous monitor update failure prevented generation of RAA".to_string(), 1);
 	// Note that nodes[1] not updating monitor here is OK - it wont take action on the new HTLC
@@ -1366,6 +1369,7 @@ fn first_message_on_recv_ordering() {
 	// the appropriate HTLC acceptance).
 	nodes[1].node.handle_update_add_htlc(&nodes[0].node.get_our_node_id(), &payment_event.msgs[0]);
 	nodes[1].node.handle_commitment_signed(&nodes[0].node.get_our_node_id(), &payment_event.commitment_msg);
+	check_added_monitors!(nodes[1], 1);
 	assert!(nodes[1].node.get_and_clear_pending_msg_events().is_empty());
 	nodes[1].logger.assert_log("lightning::ln::channelmanager".to_string(), "Previous monitor update failure prevented generation of RAA".to_string(), 1);
 
@@ -1643,7 +1647,7 @@ fn do_during_funding_monitor_fail(fail_on_generate: bool, restore_between_fails:
 		assert!(nodes[0].node.get_and_clear_pending_msg_events().is_empty());
 		if fail_on_generate && !restore_between_fails {
 			nodes[0].logger.assert_log("lightning::ln::channelmanager".to_string(), "Previous monitor update failure prevented funding_signed from allowing funding broadcast".to_string(), 1);
-			check_added_monitors!(nodes[0], 0);
+			check_added_monitors!(nodes[0], 1);
 		} else {
 			nodes[0].logger.assert_log("lightning::ln::channelmanager".to_string(), "Failed to update ChannelMonitor".to_string(), 1);
 			check_added_monitors!(nodes[0], 1);