ftp: Reset fuid after logging

A user reported being confused about the fuid association of subsequent
FTP commands when a data transfer has completed. It seems reasonable to
unset fuid upon logging a FTP command which had a fuid.

The current behavior results in the PORT or PASV commands after a RETR or STOR
to have the fuid of the prior file transfer. Similarly, any CWD or DEL commands
following a file transfer will unnecessarily be logged with the fuid of the
prior file transfer.

This tickles the baselines for the private testing PCAP a lot, primarily
because there data connections in that pcap are never established properly.
E.g, the fuids FzDzid1Dxm9srVKHXf and FEfYX73q5C6GEQZXX9 have been re-used
for multiple commands.

This may look like we're losing information, but the fuids vanishing
in the normal btests belong to a LIST command that isn't logged by
default into ftp.log. If it was, the fuid would be attached to it.

scripts/base/protocols/ftp/files.zeek

@@ -7,11 +7,6 @@
 module FTP;
 
 export {
-	redef record Info += {
-		## File unique ID.
-		fuid: string &optional &log;
-	};
-
 	## Default file handle provider for FTP.
 	global get_file_handle: function(c: connection, is_orig: bool): string;
 

scripts/base/protocols/ftp/info.zeek

@@ -72,5 +72,8 @@ export {
 
 		## Determines if the password will be captured for this request.
 		capture_password:   bool &default=default_capture_password;
+
+		## File unique ID.
+		fuid: string &optional &log;
 	};
 }

scripts/base/protocols/ftp/main.zeek

@@ -212,8 +212,9 @@ function ftp_message(c: connection)
 	# values after logging.
 	delete s$mime_type;
 	delete s$file_size;
-	# Same with data channel.
+	# Same with data channel and fuid;
 	delete s$data_channel;
+	delete s$fuid;
 	}
 
 event sync_add_expected_data(s: Info, chan: ExpectedDataChannel) &is_used