Hammer CLI

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1639748

Description of problem:

When requests to hammer take too long (over 60s by default in Sat 6.2 and over 120s in 6.3+), for some HTTP methods (GET HEAD PUT DELETE OPTIONS TRACE), the request is sent again to the server.

This can lead to `Required lock is already taken by other running tasks` error, when the task serving the update is still running.

Version-Release number of selected component (if applicable):
6.2+

How reproducible:
In some cases

Steps to Reproduce:
1. have a satellite with larger number of repositories
2. call hammer -p redhat -d organization update --id 1 --redhat-repository-url http://other-sat.example.com

Actual results:
if the request takes more than default timeout to process, there will be another request appearing after the timeout, producing the lock error.

Expected results:
if there is timeout, the hammer just exists, without any additional retires

Additional info:

We've tracked that down to ruby implementation https://github.com/ruby/ruby/blob/8778e9267c6b2f92ce7caea26fe59593cbbf2645/lib/net/http.rb#L1534, where the retry happens. In Ruby 2.5, an option set max_retries was exposed https://github.com/ruby/ruby/commit/4f4d7247208b467c3d48587d10761c23a41b140b, but the rest-client is not exposing it yet.