Change:
sender should not consider itself application limited if it would have fully utilized the congestion window without pacing delay. <del> 7.10. 7.10.1. Constants used in congestion control are based on a combination of RFCs, papers, and common practice.  Some may need to be changed or negotiated in order to better suit a variety of environments. The sender's maximum payload size.  Does not include UDP or IP overhead.  The max packet size is used for calculating initial and minimum congestion windows.  The RECOMMENDED value is 1200 bytes. Default limit on the initial amount of data in flight, in bytes. Taken from RFC6928.  The RECOMMENDED value is the minimum of 10 * kMaxDatagramSize and max(2* kMaxDatagramSize, 14600)). Minimum congestion window in bytes.  The RECOMMENDED value is 2 * kMaxDatagramSize. Reduction in congestion window when a new loss event is detected. The RECOMMENDED value is 0.5. Number of consecutive PTOs required for persistent congestion to be established.  The rationale for this threshold is to enable a sender to use initial PTOs for aggressive probing, as TCP does with Tail Loss Probe (TLP) TLP RACK, before establishing persistent congestion, as TCP does with a Retransmission Timeout (RTO) RFC5681.  The RECOMMENDED value for kPersistentCongestionThreshold is 2, which is equivalent to having two TLPs before an RTO in TCP. 7.10.2. Variables required to implement the congestion control mechanisms are described in this section. The highest value reported for the ECN-CE counter by the peer in an ACK frame.  This variable is used to detect increases in the reported ECN-CE counter. The sum of the size in bytes of all sent packets that contain at least one ack-eliciting or PADDING frame, and have not been acked or declared lost.  The size does not include IP or UDP overhead, but does include the QUIC header and AEAD overhead.  Packets only containing ACK frames do not count towards bytes_in_flight to ensure congestion control does not impede congestion feedback. Maximum number of bytes-in-flight that may be sent. The time when QUIC first detects a loss, causing it to enter recovery.  When a packet sent after this time is acknowledged, QUIC exits recovery. Slow start threshold in bytes.  When the congestion window is below ssthresh, the mode is slow start and the window grows by the number of bytes acknowledged. 7.10.3. At the beginning of the connection, initialize the congestion control variables as follows: 7.10.4. Whenever a packet is sent, and it contains non-ACK frames, the packet increases bytes_in_flight. 7.10.5. Invoked from loss detection's OnPacketAcked and is supplied with the acked_packet from sent_packets. 7.10.6. Invoked from ProcessECN and OnPacketsLost when a new congestion event is detected.  May start a new recovery period and reduces the congestion window. 7.10.7. Invoked when an ACK frame with an ECN section is received from the peer. 7.10.8. Invoked by loss detection from DetectLostPackets when new packets are detected lost. </del> 8. 8.1.

Discussion:
This seems like an unwieldy PR, so I'll state what I've done. I've simply moved all pseudocode to the appendix with no changes to text, except for the addition of a single sentence at the beginning of the appendices. It might be easier to see the rendered draft . Subsequent PRs will clean each part up.
This is a good start. I expect some of the text in the pseudocode sections will need to move up, but one step at a time.