Set the puma persistent_timeout higher than nginx

[ismarc]

If the load balancer/proxy/server in front of Conjur has
a longer timeout than Conjur, there will be 502s as Conjur will
close the connection even if there are pending requests. This
can lead to it being marked unavailable, errors returned to the
client and performance issues as nginx/load balancer in front of it

What does this PR do?

• What's changed? Why were these changes made? This specifies the puma persistent_timeout value that should be higher than any load balancer or proxy in front of Conjur. The default value is 20 seconds, shorter than nginx and most load balancer default values.

What ticket does this PR close?

Resolves

• conjurinc/ops#778 (private)
• cyberark/conjur-ecs-deploy#28 (private)

Potentially solves symptoms associated with

• conjurinc/appliance#1201 (private)
• The multitude of retries we have built in to our tests in case of intermittent gateway errors

Checklists

Change log

• The CHANGELOG has been updated, or
• This PR does not include user-facing changes and doesn't require a CHANGELOG update

Test coverage

• This PR includes new unit and integration tests to go with the code changes, or
• The changes in this PR do not require tests

Documentation

• Docs (e.g. READMEs) were updated in this PR, and/or there is a follow-on issue to update docs, or
• This PR does not require updating any documentation

API Changes

• The OpenAPI spec has been updated to meet new API changes (or an issue has been opened), or
• The changes in this PR do not affect the Conjur API

[codeclimate]

Lists should be surrounded by blank lines

[orenbm]

can you link to an issue please?

[orenbm]

how does this change affect the user?

[orenbm]

does it fix a known bug?

[ismarc]

I've added links to known-related issues in the description. The effect should be to prevent the random and spurious 502 errors frequently seen when running conjur behind a load balancer/nginx/proxy due to mismatched keepalive times, but otherwise users should not see behavioral changes. The issue was discovered for the ConjurOps v5 deployment, but is a symptom that has been seen pretty frequently in other contexts and always chalked up to transient issues.

[codeclimate]

Code Climate has analyzed commit 8a2602f and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 100.0% (50% is the threshold).

This pull request will bring the total coverage in the repository to 89.2% (0.0% change).

View more on Code Climate.

[whip113]

@ismarc sent me this little tweak for some flakiness I observed while trying to use the seed-fetcher with an AWS auto-scaling group. Note that in my setup, I did NOT have a load balancer in front of my leader, my followers connected directly to it. I had regular failures with deployed followers where some wouldn't get the seed file at all. This seemed to get markedly worse after I exceeded 30 followers (with max_wal_senders increased appropriately). After making the change to puma.rb as suggested here, I was able to roll out 90 followers with zero failures (failure rate before was approx 20%). I suggest we publish this in a KBA as well, so that customers can start benefitting from it before 12.2 is released (or even without having to upgrade to 12.2).