Update dependencies

[jtgeibel]

This PR was constructed in two phases. The first 3 commits make up phase 1 where most semver compatible versions are bumped. In the second phase I started bumping requirements in Cargo.toml.

Phase 1

The first 3 commits essentially do a cargo update with the exception of hyper which is held back at 0.11.10. A deprecation was introduced in 0.11.11. It looks like bind_connection should be replaced with serve_connection, however the API is different.

The first two commits account for:

• A minor change to the GNU header format in tar. It appears that this test is the only one we have that successfully uploads a tar file containing file contents, thus triggering the inclusion of the header.
• A deprecation in openssl.

Phase 2

The following updates required minor fixes to address API changes: flate2, env_logger, openssl, hex, lettre.

[carols10cents]

The only changes that made me a little nervous were the lettre crate changes, but i deployed to staging and emails worked!

bors: r+

[bors-voyager]

Build succeeded

• continuous-integration/travis-ci/push

[sgrif]

We've been seeing regular segfaults since the deploy which included this commit. (That deploy was 44d01f0...a2eb1f9). This is the only change in that deploy which could be the culprit. For that reason, I've reverted it.

[jtgeibel]

Hey @sgrif, I just wanted to check in and see if you were able to resolve the issues seen in production. Actual segfaults, ouch! Did you see any clues in the logs as to which routes may have been related to this?

[sgrif]

Reverting this did stop the segmentation faults, yes. The segfaults were not tied to any particular route, nor was there any pattern generally leading up to it. That said, my hunch is that it was the openssl bump that caused the issue. However, at least 4 of the crates bumped here directly use unsafe code, and that's without me checking transitive dependencies, so it could be literally anything.

@ashleygwilliams and I discussed (very briefly) about upgrading piece by piece -- I'm not sure if we want to try "the thing I think is causing the problem" first, or last. Either way, in the future, I think it will be best if we do upgrades like this in smaller batches, so it's easier to track down if something goes wrong.

[jtgeibel]

Either way, in the future, I think it will be best if we do upgrades like this in smaller batches, so it's easier to track down if something goes wrong.

Yeah, I was thinking that as well. Fortunately it should be easy to land these commits as individual PRs, and then the remaining bulk cargo update (in 5b65fd0) can be further split as well. I've also been meaning to look into https://dependabot.com/ which would help keep us from falling behind again.

In this commit series, I started with the cargo update so that I could figure out where work was needed and then it was too easy to just keep adding commits on top.