prevent leaking of CURL handles

[dgoffredo]

See #31.

In addition to the recommended change, this revision also adds unit tests that verify that a CURL handle, once created, is destroyed.

[dgoffredo]

This code is moved and renamed from the class MockCurlLibrary that used to be in the TEST_CASE("parse response headers and body"). It's used there and in the new test case.

I also added data members created_handles_, destroyed_handles_, message_result_, and delay_message_.

[pr-commenter]

Benchmarks

Comparing candidate commit 2c261a4 in PR branch david.goffredo/curl-handle-leak with baseline commit 338a87e in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 1 metrics, 0 unstable metrics.

[dgoffredo]

The SECTIONs above are all setup. The post-condition, here, is always the same: one handle created and one handle destroyed.

[dgoffredo]

I find that "hide whitespace" in the diff gearbox menu improves the diff.

[cgilmour]

Seems OK, marking as approved.
Are there any consequences to doing this with a request in-flight?

[dgoffredo]

Thanks!

Are there any consequences to doing this with a request in-flight?

Nope, removing the easy handle from the multi-handle (event loop) unregisters it from anything that would drive its installed callbacks. Then cleaning up the easy handle frees resources.