Use a connection pool

[jgaskins]

I noticed in ce72180 there was mention of a desire for a connection pool. The crystal-lang/crystal-db shard is capable of managing pools of arbitrary connection types, including HTTP::Clients — really, anything with a close method).

This commit adds DB::Pool for a thread-safe, configurable connection pool. By default, it spins up a single connection on instantiation and will close all but one connection on checking connections back into the pool. This commit does not add configurability to that connection pool, but it can be added in a followup commit.

DB::Pool is used in several of my own shards that implement network clients:

• https://github.com/jgaskins/kubernetes
• https://github.com/jgaskins/redis
• https://github.com/jgaskins/aws
• https://github.com/jgaskins/elasticsearch
• https://github.com/jgaskins/neo4j.cr (this actually uses a copy/pasted version of DB::Pool, which was the catalyst for Allow DB::Pool to be used a generic connection pool crystal-lang/crystal-db#131 enabling this functionality)

A couple other minor touches in this commit include:

• removing a nil check on @callback
• explicit assignment of that callback in before_request, favoring assignment from within the method signature
• parsing JSON/Protobuf directly from the socket instead of reading the full body into memory, avoiding having multiple representations of the response in memory at once

These would've been separate PRs, but they would not have been able to be done concurrently due to merge conflicts so I shoveled them all in here. 😄

[mloughran]

Thanks for the contribution and detailed writeup @jgaskins; this looks really helpful and I wasn't aware that DB::Pool could be used for this. Give me a couple of days to try it on our side, then I will merge this PR and release a new shard version :)

Out of interest, are you considering using twirp & crystal at shopify?

[jgaskins]

I wasn't aware that DB::Pool could be used for this.

I added it a while back. I needed a generic connection pool that was more featureful than ysbaddaden/pool — elasticity, the ability to evict broken connections, etc. I originally offered to extract DB::Pool to its own shard, but the discussion ended up heading in the direction of just keeping the connection pool in the db shard.

are you considering using twirp & crystal at shopify?

Not to my knowledge. I work on infrastructure/SRE there, so I don't work on a lot of app features. I mostly get paged when things go wrong. 😄

[mloughran]

Merged, and released as 0.3.0. Thanks again :)