Onetimepool Goroutine Leaks

[osxtest]

Description:
I found an issue while using the tlsx package, but the root cause seems to be in the utils package. Therefore, I am submitting the issue here.

Environment:

• Go version: go1.21
• System: macOS

Steps to Reproduce:

1. Run the test code in here:

package main

import (
	"crypto/tls"
	"log"
	"net/http"
	"net/http/httptest"
	_ "net/http/pprof"
	"net/url"
	"testing"

	"github.com/projectdiscovery/tlsx/pkg/tlsx"
	"github.com/projectdiscovery/tlsx/pkg/tlsx/clients"
)

func TestGoroutineLeak(t *testing.T) {
	go func() {
		log.Println(http.ListenAndServe("localhost:6060", nil))
	}()
	defer func() {
		t.Log("http://localhost:6060/debug/pprof/")
		select {}
	}()

	ts := httptest.NewUnstartedServer(nil)
	ts.TLS = &tls.Config{
		CipherSuites: []uint16{tls.TLS_RSA_WITH_RC4_128_SHA},
		MinVersion:   tls.VersionTLS10,
		MaxVersion:   tls.VersionTLS13,
	}
	ts.StartTLS()
	defer ts.Close()

	opts := &clients.Options{
		Retries:         1,
		TlsVersionsEnum: true,
		TlsCiphersEnum:  true,
	}
	service, err := tlsx.New(opts)
	if err != nil {
		panic(err)
	}
	parsed, _ := url.Parse(ts.URL)
	_, err = service.Connect(parsed.Hostname(), parsed.Hostname(), parsed.Port())
	if err != nil {
		panic(err)
	}
}

2. After running the test, visit http://localhost:6060/debug/pprof/goroutine?debug=1.
3. You should see a onetimepool goroutine leak.

Observed Output:

3 @ 0x10003daae 0x100008ef0 0x100008b37 0x100a7a9ee 0x100a7fc4f 0x100072b61
#	0x100a7a9ed	github.com/projectdiscovery/utils/conn/connpool.(*OneTimePool).Run+0x2ad		/Users/qwerty/.gvm/pkgsets/go1.21/global/pkg/mod/github.com/projectdiscovery/utils@v0.2.5/conn/connpool/onetimepool.go:78
#	0x100a7fc4e	github.com/projectdiscovery/tlsx/pkg/tlsx/tls.(*Client).EnumerateCiphers.func1+0x2e	/Users/qwerty/.gvm/pkgsets/go1.21/global/pkg/mod/github.com/projectdiscovery/tlsx@v1.1.7/pkg/tlsx/tls/tls.go:218

This trace points to a potential goroutine leak in here

utils/conn/connpool/onetimepool.go

Line 78 in 40ca4ed

p.idleConnections <- conn

Expected Behavior:
No goroutine leaks should be present.

Analysis:
The leak reason is that after pool.Acquire but before pool.Close, if the p.idleConnections channel is full, pool.Run gets stuck at sending a connection to the channel. Hence, after pool.Close, it doesn't get the chance to go to case <-p.ctx.Done(): and return.

[Mzack9999]

@osxtest Nice catch! Thanks for providing a fix!