feat(client): blocking LineSenderPool

[puzpuzpuz]

Breaking change of an experimental API

The pool now blocks if there are already too many senders in use. Pooled senders are released implicitly, via the Close call.

	sender, err := pool.Sender(ctx)
	if err != nil {
		panic(err)
	}

	// ...

	// Close call returns the sender back to the pool
	if err := sender.Close(ctx); err != nil {
		panic(err)
	}

[puzpuzpuz]

@sklarsa I tried making the pool behave similarly to the "traditional" connection pools, i.e. you obtain a connection (sender in our case) with a call to the pool and then close the connection when you're done. Now it also blocks if there is already the maximum number of pooled senders. WDYT?

[sklarsa]

@sklarsa I tried making the pool behave similarly to the "traditional" connection pools, i.e. you obtain a connection (sender in our case) with a call to the pool and then close the connection when you're done. Now it also blocks if there is already the maximum number of pooled senders. WDYT?

This is very cool! Definitely more along the lines of how I originally envisioned the pool concept.

[puzpuzpuz]

@sklarsa thanks for the comprehensive review!