dropbox_api dependency restricts faraday versions

[jrochkind]

The dropbox_api gem oddly limits to faraday <= 1.0, meaning 1.0.0 is allowed but 1.0.1 (or 1.1.0) are not. (Both 1.0.1 and 1.1.0 are existing faraday releases).

Jesus/dropbox_api#71

This means an app that uses browse-everything is prevented from using a faraday version past 1.0.0. Meaning losing out on bugfixes or performance improvements in (eg) 1.0.1, and also potential for conflict if some other dependency wants eg faraday 1.1.x.

Options:

1. Somehow help/get dropbox_api to fix this.

2. Move to a different dependency than dropbox_api. We are using dropbox_api which has most recent release December 2019, 136 github stars and 1,049,324 total downloads on rubygems. There is also [dropbox_api](https://github.com/zendesk/dropbox-api] which has a more recent release (April 2020), more stars on github (356), but fewer total downloads. on rubygems. They both only have pre-1.0 releases. It's honestly not clear if either of them is especially well maintained.

   • There's also a dropbox gem, with an actual post 1.0 release, but last release was in 2011, and it has fewer downloads -- although more github stars than any (529). It's really unclear what the most maintained ruby dropbox gem is.
   • omg here's a whole list of 7 dropbox gems from 2018. https://www.xuuso.com/programming/2018/11/15/a-summary-of-dropbox-gems.html . It doesn't seem to include any more that are actually currently maintained.
   • I suppose a sub-possiblity of this one is making our own new dependency, perhaps forking dropbox_api . I suspect there is no appetite for this though, we already have more maintenance work than we can really afford.

3. Make dropbox_api an "optional" dependency. There isn't an "optional" dependency feature in rubygems, this would mean making it not a formal dependency, but using runtime logic to load it if present, insist on certain versions if desired (although sincce dropbox_api is still pre-release 1.0 without semver, there probably aren't desirable version restrictions), and complain if you try to use dropbox features without it. While an informal pattern, this is for example what Rails does with database adapters, such as pg -- no need to make every app using Rails have a dependency on every possible database adapter Rails could work with. This seems analagous.

   • Technically backwards incompat, because apps updating, if using dropbox, would have to add dropbox_api to their Gemfiles manually. This is unfortunate, becuase otherwise I would consider this a fine solution. But I suspect people won't want to release a 2.0 with only this change, although there is no technical reason not to.
   • we could choose to knowingly violate semver and release a 1.x with this change anyway.

4. Do nothing, just accept that apps with a dependency on b-e (including indirect dependencies) won't be able to use browse-everthing past 1.0.0, won't be able to update to 1.0.1.