Fix metrics on outstanding incoming connections

[lijunwangs]

Problem

outstanding_incoming_connection_attempts in quic streamer is off when the incoming fails and we fail to reduce the count. This causes the metric non-reliable.

Summary of Changes

subtract in the error case as well.

Fixes #

[lijunwangs]

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.

Project coverage is 83.2%. Comparing base (87451d5) to head (e32562f).
Report is 4 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##           master    #6906     +/-   ##
=========================================
- Coverage    83.2%    83.2%   -0.1%     
=========================================
  Files         852      852             
  Lines      377089   377092      +3     
=========================================
- Hits       314051   314038     -13     
- Misses      63038    63054     +16     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[alexpyattaev]

LGTM but would be interesting to know what the Err case even is - it would imply we could not send the Accept packet for some reason.

[lijunwangs]

One of the following

TransportError, Reset, TimeOut, CidsExhausted.. We probably should build better metrics to understand it more.

pub enum ConnectionError {
    /// The peer doesn't implement any supported version
    #[error("peer doesn't implement any supported version")]
    VersionMismatch,
    /// The peer violated the QUIC specification as understood by this implementation
    #[error(transparent)]
    TransportError(#[from] TransportError),
    /// The peer's QUIC stack aborted the connection automatically
    #[error("aborted by peer: {0}")]
    ConnectionClosed(frame::ConnectionClose),
    /// The peer closed the connection
    #[error("closed by peer: {0}")]
    ApplicationClosed(frame::ApplicationClose),
    /// The peer is unable to continue processing this connection, usually due to having restarted
    #[error("reset by peer")]
    Reset,
    /// Communication with the peer has lapsed for longer than the negotiated idle timeout
    ///
    /// If neither side is sending keep-alives, a connection will time out after a long enough idle
    /// period even if the peer is still reachable. See also [`TransportConfig::max_idle_timeout()`]
    /// and [`TransportConfig::keep_alive_interval()`].
    #[error("timed out")]
    TimedOut,
    /// The local application closed the connection
    #[error("closed")]
    LocallyClosed,
    /// The connection could not be created because not enough of the CID space is available
    ///
    /// Try using longer connection IDs.
    #[error("CIDs exhausted")]
    CidsExhausted,
}

[alexpyattaev]

I guess we need to set up a way to monitor logs on our canaries for contents of these errors. Just pooling counts into metrics would not help - we will probably need to see context of these events.