Use sidekiq concurrency field to set DB_POOL

[abbottmg]

There are really two stages to this PR to consider.

The easy one is allowing deployment-sidekiq to set the DB_POOL env variable per sidekiq worker definition. The second one specifically sets it to the concurrency value rather than using an independent key. My memory is that sidekiq should never need more DB connections than it has threads, so this reduces connection overhead for workers with low duty cycles (eg a worker dedicated to one of the scheduler, mailers, and potentially ingress queues).

[timetinytim]

As far as I can tell this should be fine, though @renchap is more familiar with exactly how this work, and can confirm whether this should be alright.