Travis improvements

[barryvdh]

Some improvements for Travis, which will speed it up a bit.

Also adds tests for 7.1 and tests the lowest version of the dependencies, eg. Symfony 2.7 instead of 3

• Cache Composer files
• Add php 7.1
• Install lowest + normal dependencies

[stof]

you should cache only the /files subfolder, to avoid invalidating the Travis cache on each builds because of the packagist metadata cache (builds on this repo are not happening often enough to benefit from the metadata cache anyway, as the cache will almost always be stale for next builds)

[barryvdh]

Does stale packagist metadata also invalidate the files then? I've updated the code, but if possible, I'm very interested in a source for this (as I use this exact code in multiple repositories).

[stof]

the composer cache folder contains several subdirectories:

• files: contains downloaded archives (or downloaded single files for a mostly unknown).
• vcs: contains clones of VCS repositories referenced directly (or also installed from source for git repositories in recent composer versions if your git version is new enough to support the necessary feature)
• repositories: contains metadata files downloaded from composer repositories (packagist, satis, etc...)

As this Travis build installs stable releases of its dependencies, there is a good chance to have a cache hit for downloads (and these archives are bigger than metadata, making it a good idea to hit the cache). When the dependency makes a new release, we will miss the cache, and we will indeed also force Travis to store an updated cache at the end of the build.
On the other hand, Packagist metadata would almost always miss the cache (Packagist receives updates very often), and the package metadata we need (the Symfony component for instance) are unlikely to end up in the file containing packages not updated since months (Symfony is updated every few days).
So the metadata cache will not help us (we will still have to download them), and so the cost of downloading the Travis cache from the S3 and uploading the new cache to the S3 at the end of the build (as it will be updated each time) will not be outweighted by benefits.