Trace connection durations

[crocodile-dentist]

Description

It may be useful for some diagnostic purposes to know how long lived
an outbound hot connection has been. This patch introduces tracing
when a hot peer is demoted or errors out with the active time in seconds.

Checklist

Quality

• Commit sequence makes sense and have useful messages, see ref.
• New tests are added and existing tests are updated.
• Self-reviewed the PR.

Maintenance

• Linked an issue or added the PR to the current sprint of ouroboros-network project.
• Added labels.
• Updated changelog files.
• The documentation has been properly updated, see ref.

[coot]

The life time of inbound / outbound connection ought to be measured by the connection manager, as it knows enough about a connection to do that. It can also measure lifespan of a connection (which could be longer than either of them).

However, connection manager doesn't know about protocol temperature, so it cannot measure how long a peer was hot or remote hot - and this should be logged by peer selection actions and inbound governor respectively.

[crocodile-dentist]

Are we actually interested in knowing the connection duration at the handler level? I thought about that and didn't find the metric useful enough in general and so decided against implementing re your first point. If we want to track outbound duration to big ledger peers, the connection duration might not give an accurate result if the connection was used via the inbound side strictly at least some of the time. This implementation will give the connection durations separately for outbound and inbound sides via patches in the inbound governor and peer state actions (via peer connection handle, so the duration can be exposed to peer selection governor easily in the future if we do decide to implement a max duration policy).

[karknu]

For this to be usable in the way we discussed I think that the lifetime for the hot connections must be included in the DebugSt data too.

We are looking for the life time of the longest lived connections, and they may still be active. That is emitting a trace event for hot demotions won't capture these connections.