switch ci to stack and add ci cron job to test hackage breakage

[soenkehahn]

This uses the experimental cron job feature by travis: https://docs.travis-ci.com/user/cron-jobs/

It uses stack for the normal push-triggered CI.

The cron job script still uses tinc. We could switch this to stack once this is fixed: commercialhaskell/stack#2475

[jkarni]

Relates to #565

[jkarni]

Why install cabal-install via stack? Why even install stack in the first place? So that we can install ghc?

[soenkehahn]

The install section of the .travis.yml also gets executed for cron jobs. (That's where stack is installed: https://github.com/haskell-servant/servant/pull/568/files#diff-354f30a63fb0907d4ad57269548329e3R18 .) So when executing ci-cron.sh on travis we already have stack. But no ghc and no cabal-install. So I thought it would be easiest to just use stack's ghc and use it to install cabal-install.

Alternatively we could install ghc and cabal-install from hvr's repos, like before. That would have the disadvantage of slowing down the push-triggered builds unnecessarily.

Generally the ci-cron.sh script is not really how I want it to be. But I think it should be worked on in follow-up PRs. So that we can get the stack CI in place. (And I think it's already better than what we have now.)

[jkarni]

I'm okay with or without this change. My opinion has been that stackage itself has pretty good infrastructure for testing breakage of their package sets, and they are very good about notifying us about issues, so I don't tend to worry too much about stackage breakage. That said, more testing isn't a bad thing.

[soenkehahn]

What we didn't have (before this PR) is CI that checks that the state on master works with stack. This was also broken more than once on master. stackage doesn't help with that.

I still have to make sure that the cron job succeeds, then I'll merge.

[jkarni]

@soenkehahn fair point. I'm in favor of the change, then.

But CI is broken :) . Looks like an issue with wai-app-static?