CICD: fix short test flag and up parallelism

[onetechnical]

Summary

The flags to run short tests were not correct in the GitHub Actions conversion of PR tests. This fixes that.

Additionally, parallelism was not enabled, and seems to have a pretty good effect at 4, so this was added.

These changes have the benefit of reducing PR checks in GitHub Actions to around 22 minutes.

Test Plan

Ran through GitHub Actions PR Tests multiple times. Please verify these work correctly on this PR as well.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 50.46%. Comparing base (807b29a) to head (9d3ed6e).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6370      +/-   ##
==========================================
- Coverage   50.59%   50.46%   -0.14%     
==========================================
  Files         653      653              
  Lines      110395   110395              
==========================================
- Hits        55859    55715     -144     
- Misses      51661    51817     +156     
+ Partials     2875     2863      -12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jannotti]

OK, I see, we can tell by how long they ran. I only see 18 jobs running after about 3 minutes. So I think I'd recommend going to 8 for expect 6 for PR tests.

It would be cool if we could bind our fast jobs together to run serially as one job. That way all the expect and PR test chunks could get started at the beginning. But I still think we'll get a win from more jobs.

Could we do all the reviewdog stuff together?

Do the results of the build step get used by the others, so they have to wait? If so, we really want to speed that up at all costs. Maybe we should instrument travis/build.sh with some calls to date so we can see what is slow during the 5m "build" step inside the "build" job".

[onetechnical]

Implemented with expect, and looks pretty good: 17m58s. Way better than on circle which ran with way more parallels!

From the timing I'm not sure we can get further wins by re-arranging things - e2e_subs is the tentpole.

I'm inclined not to combine all the other items together, in that it's easier to parse what failed if anything fails The rest of the checks seem pretty fast. Could be convinced otherwise, if anyone feels strongly.