What is the lifetime of transport stats?

[fippo]

Follow-up on #619:

https://jsfiddle.net/fippo/phsyg23j/
shows the lifetime of transport stats. The first log line has two transports, one of these is typically thrown away as BUNDLED. We should probably not expose transport stats until the signaling state is stable if that part of #802 can be shipped.

The second part of the fiddle shows that transport stats are exposed when the peerconnection is not connected.
What makes RTP stats different from transport stats here?
Why does "no packets no stats" not apply?

[alvestrand]

From the fiddle:

[{
bytesReceived: 0,
bytesSent: 0,
dtlsRole: "client",
dtlsState: "new",
iceLocalUsernameFragment: "kZMn",
iceRole: "controlling",
iceState: "new",
id: "T01",
localCertificateId: "CFC9:40:E4:6B:33:80:D3:D6:56:4D:AE:BE:E0:3C:B3:72:77:BE:6C:9B:53:F1:AD:BF:71:CE:B9:4F:00:16:3E:80",
packetsReceived: 0,
packetsSent: 0,
selectedCandidatePairChanges: 0,
timestamp: 1743454497529.193,
type: "transport"
}]

Note that the localCertificateId, the iceRole, and the iceLocalUsernameFragment all contain non-zero information.

[fippo]

https://jsfiddle.net/fippo/phsyg23j/1/ with roles reversed.

I'm surprised iceLocalUsernameFragment is an empty string before SLDd but that is fixable.
remoteCertificateId not being set makes sense since the certificate is not known before the DTLS handshake finishes.

[fippo]

The way to prevent this from showing up too early (two transport objects) would be to gate this on dtlsRole being set. local and remote certificate ids (maybe? When do certificate stats exist?) will not be known but it is what it is.

For the (quite real) edge case of ICE and DTLS becoming established before the remote description arrives the transport would show up as receiving the remote dtls client hello would establish the dtls role.