By default sort network addrs before inclusion in node_announcements

In  #797, we stopped enforcing that read/sent node_announcements
had their addresses sorted. While this is fine in practice, we
should still make a best-effort to sort them to comply with the
spec's forward-compatibility requirements, which we do here in the
ChannelManager.

lightning/src/ln/channelmanager.rs

@@ -1743,13 +1743,17 @@ impl<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelMana
 	/// only Tor Onion addresses.
 	///
 	/// Panics if addresses is absurdly large (more than 500).
-	pub fn broadcast_node_announcement(&self, rgb: [u8; 3], alias: [u8; 32], addresses: Vec<NetAddress>) {
+	pub fn broadcast_node_announcement(&self, rgb: [u8; 3], alias: [u8; 32], mut addresses: Vec<NetAddress>) {
 		let _persistence_guard = PersistenceNotifierGuard::new(&self.total_consistency_lock, &self.persistence_notifier);
 
 		if addresses.len() > 500 {
 			panic!("More than half the message size was taken up by public addresses!");
 		}
 
+		// While all existing nodes handle unsorted addresses just fine, the spec requires that
+		// addresses be sorted for future compatibility.
+		addresses.sort_by_key(|addr| addr.get_id());
+
 		let announcement = msgs::UnsignedNodeAnnouncement {
 			features: NodeFeatures::known(),
 			timestamp: self.last_node_announcement_serial.fetch_add(1, Ordering::AcqRel) as u32,

lightning/src/ln/msgs.rs

@@ -390,6 +390,17 @@ pub enum NetAddress {
 	},
 }
 impl NetAddress {
+	/// Gets the ID of this address type. Addresses in node_announcement messages should be sorted
+	/// by this.
+	pub(crate) fn get_id(&self) -> u8 {
+		match self {
+			&NetAddress::IPv4 {..} => { 1 },
+			&NetAddress::IPv6 {..} => { 2 },
+			&NetAddress::OnionV2 {..} => { 3 },
+			&NetAddress::OnionV3 {..} => { 4 },
+		}
+	}
+
 	/// Strict byte-length of address descriptor, 1-byte type not recorded
 	fn len(&self) -> u16 {
 		match self {