Indicate send blocking in data_moved events

Fixes #132 (if merged).

It struck me that its the "data_moved" action that can be blocked, so rather than add
a separate event, just add an optional field to an existing event. This helps ensure we
can represent both stream and datagram data with all relevant fields.

draft-ietf-quic-qlog-quic-events.md

@@ -1200,6 +1200,12 @@ processed first and afterwards the application layer reads from the streams with
 newly available data). This can help identify bottlenecks, flow control issues,
 or scheduling problems.
 
+The `blocked_reason` field supports optional logging of information related to
+stream writes getting blocked, either in full or in part. For example, if an
+application intended to write data to a stream but was blocked from sending
+anything due to congestion control, it can log the `congestion_control` reason
+and omit the length field.
+
 The `additional_info` field supports optional logging of information
 related to the stream state. For example, an application layer that moves data
 into transport and simultaneously ends the stream, can log `fin_set`. As
@@ -1222,6 +1228,8 @@ QUICStreamDataMoved = {
     ? from: $DataLocation
     ? to: $DataLocation
 
+    ? blocked_reason: $BlockedReason
+
     ? additional_info: $DataMovedAdditionalInfo
 
     ? raw: RawInfo
@@ -1233,6 +1241,15 @@ $DataLocation /=  "application" /
                   "transport" /
                   "network"
 
+$BlockedReason /= "scheduling" /
+                  "pacing" /
+                  "amplification_protection" /
+                  "congestion_control" /
+                  "connection_flow_control" /
+                  "stream_flow_control" /
+                  "stream_id" /
+                  "application"
+
 $DataMovedAdditionalInfo /= "fin_set" /
                             "stream_reset"
 ~~~
@@ -1259,6 +1276,12 @@ are processed first and afterwards the application layer reads all Datagrams at
 once). This can help identify bottlenecks, flow control issues, or scheduling
 problems.
 
+The `blocked_reason` field supports optional logging of information related to
+stream writes getting blocked, either in full or in part. For example, if an
+application intended to write data to a stream but was blocked from sending
+anything due to congestion control, it can log the `congestion_control` reason
+and omit the length field.
+
 This event is only for data in QUIC Datagram Frames. For data in QUIC streams,
 see the `stream_data_moved` event defined in {{quic-streamdatamoved}}.
 
@@ -1270,6 +1293,8 @@ QUICDatagramDataMoved = {
     ? to: $DataLocation
     ? raw: RawInfo
 
+    ? blocked_reason: $BlockedReason
+
     * $$quic-datagramdatamoved-extension
 }
 ~~~