Disable Excon sockets thread cache

[alan]

This is the cause of the memory leak that we experienced recently.

Every Excon connection has a cache of sockets that ensures that a socket is only
used by a specific thread during its lifetime. This means that 1 Excon
connection might hold any number of open sockets to the same server.

In our case for example if Puma is running with 4 threads, and a connection pool
of 4 Excon connections to the PVB API it means that there will a maximum of 16
HTTP persistent connections.

The issue is that the implementation of the cache doesn't clear old connections
for threads that are no longer running (an issue when Puma is configured to
autoscale threads). We inadevertedly solved the memory leak by configuring Puma
to use a fixed number of threads.

The implementation of this cache was changed just before we started having
memory leaks to fix a use case of Excon that we don't use. The old
implementation didn't have a memory leak with our use case.

Although this makes the PrisonVisits::Client not thread safe it's fine in our
use case because:

• we use a connection pool of connections and a connection is only used by 1
  thread at a time.
• It means that we don't hold sockets open unnecessarily for each Excon
  connection.

I've tested the value of this setting locally by load testing the server with
concurrent requests:

• with the cache enabled and Puma autoscaling threads it showed the memory
  leak when spacing the load testing by 1 minute between benchmarks
• with the cache disabled and Puma autoscaling threads memory usage remained
  stable and there were no threading issues.

Excon discussion about the recent
change to the cache where it actually mentions that it has an memory leak issue.

[alan]

Opened an issue for Excon: excon/excon#651

[StupidCodeFactory]

same as in the corresponding PR in pvb2