.travis.yml: enable caching for dep

[AlexNPavel]

Description of the change: Enables caching for dep. This should improve CI times, but can cause problems if dep's cache gets corrupted. See this PR for more info: golang/dep#1293 (comment). We may manually have to reset the cache in the case of corruption.

Motivation for the change: Speed up CI. Closes #1062

[fabianvf]

It may also be useful to have a pre-stage that builds and caches the operator-sdk binary, so that the Ansible and Helm stages can skip dep ensure + build entirely

[AlexNPavel]

It may also be useful to have a pre-stage that builds and caches the operator-sdk binary, so that the Ansible and Helm stages can skip dep ensure + build entirely

That would be nice, but it's unfeasible due to the way that travis caching works. Travis just bundles up the entire directory as an archive that gets downloaded and extracted to the machine, and if something changes, that directory gets rearchived and uploaded. To prevent cache conflicts between builds, we would need to have separate binary for each build (maybe by appending the git SHA), which would result in an archive that could easily reach GBs in size within a week. Sadly, travis doesn't seem to provide any build-local caches. In this case, caching dep is a bit more reasonable (though the dep cache for the SDK is still very large at 2.3GB for current master).

To speed up build time, we could cache ~/.cache/go-build (which would allow for near instant compile during the build phases), but again we have the issue of a very large cache (164MB for current master and Go 1.10.3).

[AlexNPavel]

/hold
It might not be reasonable to store the 2.3GB dep cache in travis's cache. If we store our vendor in git (currently ~59M), that would result in dep taking only a couple of seconds and avoid having a monstrous cache. We should discuss this more before merging this PR.

[AlexNPavel]

/hold