LG-643 Add timeout to Twilio API calls

[monfresh]

Why: It is a best practice — some might say a requirement — to add a
timeout to all network requests. Without a timeout, some requests could
tie up an app server for literally more than 15 minutes, as reported by
New Relic.

How:

• Define an http_client with a configurable timeout option and modify
  the Twilio REST client to use this http_client
• Rescue the Faraday::TimeoutError in the Twilio service class, and
  raise a custom Twilio error that the 2FA controller can process to
  display a helpful message to the user and make it easier for them to try
  again.

*How to test locally:

• Run bundle open twilio-ruby to open the gem in your text editor
• In lib/twilio-ruby/rest/api.rb change the value of @base_url to
  'https://httpstat.us', and @host to 'httpstat.us'
• In lib/twilio-ruby/rest/api/v2010.rb, change the value of @version
  to an empty string
• In lib/twilio-ruby/rest/api/v2010/account/message.rb, on line 27,
  change the value of @uri to "/200". On line 120, replace the
  payload with this:

payload = @version.create(
              'GET',
              @uri,
              data: data,
              params: { sleep: '10000' }
          )

• Run bundle list twilio-ruby to get the path to the gem
• Copy the path of the gem and update the Gemfile to point to your local
  gem: gem 'twilio-ruby', path: [path_to_gem]
• Run bundle update twilio-ruby
• In your local application.yml, set telephony_disabled to 'false'
• Run make run
• Create an account and use your real phone number for 2FA (to minimize
  the chances of spamming someone else's phone). You should see a flash
  message saying the server took too long after you enter your phone
  number.

Hi! Before submitting your PR for review, and/or before merging it, please
go through the checklists below. These represent the more critical elements
of our code quality guidelines. The rest of the list can be found in
CONTRIBUTING.md

• When adding a new controller that requires the user to be fully
  authenticated, make sure to add before_action :confirm_two_factor_authenticated
  as the first callback.

• Unsafe migrations are implemented over several PRs and over several
  deploys to avoid production errors. The strong_migrations gem
  will warn you about unsafe migrations and has great step-by-step instructions
  for various scenarios.

• Indexes were added if necessary. This article provides a good overview
  of indexes in Rails.

• Verified that the changes don't affect other apps (such as the dashboard)

• When relevant, a rake task is created to populate the necessary DB columns
  in the various environments right before deploying, taking into account the users
  who might not have interacted with this column yet (such as users who have not
  set a password yet)

• Migrations against existing tables have been tested against a copy of the
  production database. See LG-228 Make migrations safer and more resilient #2127 for an example when a migration caused deployment
  issues. In that case, all the migration did was add a new column and an index to
  the Users table, which might seem innocuous.

• The changes are compatible with data that was encrypted with the old code.

• GET requests are not vulnerable to CSRF attacks (i.e. they don't change
  state or result in destructive behavior).

• When adding user data to the session, use the user_session helper
  instead of the session helper so the data does not persist beyond the user's
  session.

• Tests added for this feature/bug

• Prefer feature/integration specs over controller specs

• When adding code that reads data, write tests for nil values, empty strings,
  and invalid inputs.

[jmhooper]

This looks good but you've upset code climate. Since the classes that it is angry about are mocking Twilio's API we should be good to ignore those.

[monfresh]

Yeah, I thought it was Reek, but I think it's the top-level Code Climate argument-count check, which last I checked, cannot be disabled on a per-file basis, which means we'll need to disable it globally, which I'd rather not do. I believe we can tell it to ignore this offense for this PR only via the CC website. I will give that try.

[jmhooper]

Ah lame. Oh well, if not we can do an admin merge to push past it.