Expand Conn::Info$duration comment to clarify TCP end-of-connection handling

From Vern in GH-846: This is a conscious decision in the TCP analysis to
consider a connection's "duration" to run up through the end of its
productive (= data can be delivered) lifetime, not extending beyond that. So
once it's closed, packets seen subsequently (until the state-holding for the
connection times out) get processed in terms of updating the associated
history, but not the duration. This can include (unnecessarily) retransmitted
data packets, like in one of the examples above. An advantage of this definition
of "duration" is it allows more accurate computation of connection data rates.

scripts/base/protocols/conn/main.zeek

@@ -30,8 +30,16 @@ export {
 		## An identification of an application protocol being sent over
 		## the connection.
 		service:      string          &log &optional;
-		## How long the connection lasted.  For 3-way or 4-way connection
-		## tear-downs, this will not include the final ACK.
+		## How long the connection lasted.
+		##
+		## .. note:: The duration doesn't cover trailing "non-productive"
+		##    TCP packets (i.e., ones not contributing new stream payload)
+		##    once a direction is closed.  For example, for regular
+		##    3-way/4-way connection tear-downs it doesn't include the
+		##    final ACK.  The reason is largely historic: this approach
+		##    allows more accurate computation of connection data rates.
+		##    Zeek does however reflect such trailing packets in the
+		##    connection history.
 		duration:     interval        &log &optional;
 		## The number of payload bytes the originator sent. For TCP
 		## this is taken from sequence numbers and might be inaccurate