Builds take a long time because of grpcio

[codeboten]

Currently each build takes a long time as it's rebuilding grpcio. This is causing pain for maintainers trying to merge multiple changes quickly.

[c24t]

A quick check shows that the "building wheel for grpcio" step in the otcollector test takes ~20% of the total build time:

https://docs.google.com/spreadsheets/d/1f1qqfLHKRaLCwo8Y1rH21vTts8oZHIvRBfsgM9hasEY/edit?usp=sharing

[codeboten]

Just adding some notes around experiments:

Was able to shave off about 10 minutes of total build time (our current average is about 45 minutes total build time) by removing the step to update pip. Build job here: https://travis-ci.org/github/open-telemetry/opentelemetry-python/builds/687294602. The experiment code can be found in this PR #693

I also split out lint/docker-tests/docs as those can be done in parallel.

I ran some tests of running tox with parallel mode enabled, and in travis, build duration seemed worst. I configured it using -p auto which enabled 2 parallel tox targets, Locally running -p created all sorts of problems with package installation that I wasn't able to get around even when I enabled alwayscopy in tox.

GitHub actions support up to 20 simultaneous workers, but it does not support python 3.4 by default. I'm sure it would be possible to install it in a vanilla ubuntu environment, but I did not go that far down that route. It's also worth noting that running the tests in gh-actions, I ran into a segfault test failure with mysql in python 3.5 and 3.6, did not investigate further, but I do remember running into a mysql + ssl segfault some time ago, due to import ordering.

[lzchen]

We aren't going to do this. Builds have changed significantly since this.