Add Cibir tests to Connection Pool tests

[anrossi]

Description

Add CIBIR tests back to the connection pool API tests.

Testing

Adding new tests

Documentation

N/A.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.08%. Comparing base (9348a4a) to head (de71b76).
Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4952      +/-   ##
==========================================
- Coverage   87.37%   87.08%   -0.29%     
==========================================
  Files          57       57              
  Lines       17951    17982      +31     
==========================================
- Hits        15685    15660      -25     
- Misses       2266     2322      +56     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[ProjectsByJackHe]

I stepped through GDB to try and figure out why https://github.com/microsoft/msquic/actions/runs/14206028558/job/39804328737?pr=4952 is failing, and it seems to be because of a watchdog timeout firing. (Not in this PR) Could we cut down on the flakiness by increasing the timeout or something?

[anrossi]

We can increase the timeout, but it's timing out after 60 seconds. Shouldn't a handshake, even with loss, complete well before then? From: Jack He ***@***.***> Sent: Tuesday, April 1, 2025 3:31 PM To: microsoft/msquic ***@***.***> Cc: Anthony Rossi ***@***.***>; Author ***@***.***> Subject: Re: [microsoft/msquic] Add Cibir tests to Connection Pool tests (PR #4952) I stepped through GDB to try and figure out why https://github.com/microsoft/msquic/actions/runs/14206028558/job/39804328737?pr=4952 is failing, and it seems to be because of a watchdog timeout firing. (Not in this PR) Could we cut down on the flakiness by increasing the timeout or something? - Reply to this email directly, view it on GitHub<#4952 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJ3Z7EDKBXHLQH56VTWMY7T2XMHSTAVCNFSM6AAAAABZ54I5ISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZQHAZDQOBYGQ>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>> [ProjectsByJackHe]ProjectsByJackHe left a comment (microsoft/msquic#4952)<#4952 (comment)> I stepped through GDB to try and figure out why https://github.com/microsoft/msquic/actions/runs/14206028558/job/39804328737?pr=4952 is failing, and it seems to be because of a watchdog timeout firing. (Not in this PR) Could we cut down on the flakiness by increasing the timeout or something? - Reply to this email directly, view it on GitHub<#4952 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJ3Z7EDKBXHLQH56VTWMY7T2XMHSTAVCNFSM6AAAAABZ54I5ISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZQHAZDQOBYGQ>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[ProjectsByJackHe]

We can increase the timeout, but it's timing out after 60 seconds. Shouldn't a handshake, even with loss, complete well before then?

I enqueued a re-run. But given the previous 2 enumerations took 40+ seconds, it may be the case that we are doing many many handshakes with loss and it's just taking too long. Unless you're more familiar with that test and it's timing out on a SINGLE handshake (with loss). If that's the case, we'll need to investigate that.