We should avoid recursion, as it makes reasoning about stack growth
harder. This tool shows (currently) 4 (non-tail) recursive functions, at
least 2 of which are easy to fix.
Also reduce number of people in conference to 5, because on Circle CI the
test times out trying to connect more than 6 or 7 people. The persistent
conferences PR will improve this so we can set it much higher then.
Since trusty has more up-to-date packages, we can remove some of the
custom install code. Also, we're not using hstox at the moment, so there
is no need to slow down the builds for now.
Still run all the jobs during cron and regular push to branch. We
disabled build for push to branch, so cron is the only place where all
builds are run. This also means we need to worry less about spending time
in nightly builds, because they occur only once a day.
See https://github.com/travis-ci/travis-ci/issues/9071
Travis has upadted their VM image and by default the latest is being used.
This has caused our Windows builds to fail due to them exceeding Travis's log
limit of 4mb. It appears to be due to the new Docker version the new Trusty
image has, it somehow changed network behaviour in a way that makes toxcore
network module output a lot more of log messages than it used to.
Given that it fails about 80-90% of the time, it's not worth requiring
it to pass. Instead, we'll need to manually look at the osx build to see
in what way it failed.
Also, set `fast_finish` to true, since OSX regularly has multi-hour (up
to half a day) outages that can't block us for trivial code changes or
non-code changes.
Also, fix the hstox build that was taking half an hour. It now takes 5 minutes.
Also, perform distcheck on travis to ensure that make dist works. It's not
actually failing the build at the moment due to broken tests.
This is in preparation for having multiple types of build. One of the future
builds will be a hstox build, another may be frama-c or some other static
analyser. It makes sense to split these up into multiple builds, because each of
them can take a while, and running them in parallel will speed things up. Also,
the hstox test coverage should be reported separately from the toxcore auto_test
coverage.