HTTP Client's ConnectionPool erroneously leaks memory, then panics when releasing nodes at full capacity

[ghost]

Zig Version

0.11.0-dev.3892+0a6cd257b

Steps to Reproduce and Observed Behavior

When the HTTP client's ConnectionPool attempts to release a used connection into its pool of free connections, if the pool of free connections is already at capacity, the ConnectionPool will free one of the open connections it already contains, but then it will not add the previously used connection to its pool to compensate for this removal. This results in an orphaned node which has its memory leaked.

In addition, each time this occurs the ConnectionPools "free_len" value will not be decremented even though the actual length of the free pool has decreased. Eventually, this leads to a situation where the ConnectionPool's free_len value will tell it that it already has the maximum desired amount of free connections when in fact it has zero free connections. At this point it will attempt to remove a node from its now empty free pool at which point the program will panic.

    // lib/std/http/Client.zig line #87
    pub fn release(pool: *ConnectionPool, client: *Client, node: *Node) void {
        pool.mutex.lock();
        defer pool.mutex.unlock();

        pool.used.remove(node);

        if (node.data.closing) {
            node.data.deinit(client);

            return client.allocator.destroy(node);
        }

        if (pool.free_len + 1 >= pool.free_size) {
            const popped = pool.free.popFirst() orelse unreachable; // <-- This is the line that causes the panic

            popped.data.deinit(client);

            return client.allocator.destroy(popped); // <-- This is the early return that I suspect is the sole culprit of the bug.
        }

        if (node.data.proxied) {
            pool.free.prepend(node);
        } else {
            pool.free.append(node);
        }

        pool.free_len += 1;
    }

Here is a minimal reproduction of the error with tests for the memory leak and the panic.
connection_error_repro.zip

Expected Behavior

Presumably repeatedly making and then deinitializing http requests should not be causing either memory leaks or panics due to hitting unreachable code.