Run Rubocop in parallel with tests

[marcotc]

We only need to run rubocop once in our CI, but today we run it for each Ruby version, serially with tests. This slows down total CI time by ~26s.

It also gives us a clearer view of what failed (tests or linting?), as today lint failures will get reported as test failures.

This PR moves rubocop to a separate lint step.
This step runs in parallel with all tests and is a required step for deploy prerelease Gem and deploy release steps.

[delner]

Might we want to run it for each version of Ruby? It's possible that different versions of Ruby have different rules, specific to features they implement. Ideally this would never happen, but it has been the case where we've done Ruby version specific patching before.

[marcotc]

@delner that makes sense.
I was thinking running only for our configured TargetRubyVersion (2.1 in our case) would give us the same results as running on other versions too.

I can test this on all version we support and report back.

[marcotc]

@delner I double checked and because we specify TargetRubyVersion, Rubocop will always run the same set of rules regardless of the version of Ruby processing our .rubocop.yml.

To make sure all was true for our project, I ran rubocop --show-cops on all our supported Ruby versions and they all yielded the same output.

With this in mind, I think it's best to run the latest version of Rubocop, keeping a fixed TargetRubyVersion that matches our minimum required Ruby version. This ensures we have access to recent bug fixes for Rubocop.
To use the currently latest version Rubocop we need Ruby >= 2.3.
I'm updating the container running our Rubocop check to use the latest version of Ruby we support, to ensure we can easily upgrade Rubocop when desired.

[delner]

Moving linting into its own step is fine. Just one comment; address or merge at your discretion.

[delner]

Only concern here is the linting rules for 2.6 might be different than other versions (e.g. new syntax is introduced that is preferred to older versions.) This concern generally applies moving forward to all versions of Ruby, as the same thing could happen in any future version.

Not a huge deal to me, just a potential gap I see.

[marcotc]

Setting TargetRubyVersion to 2.1, like we do, prevents Rubocop from considering any rules created for versions greater than 2.1.

Effectively we "locked" Rubocop in the 2.1 era for cops.
Also, we are locked to a specific version of Rubocop, 0.49.1, so that gem's code is always consistent for us.

[marcotc]

@delner, I've rebased this PR with master, now that the CircleCI refactor has been merged. Could you take a look at this again?

[delner]

@marcotc Can you rebase this again? I'll approve and merge then.

[marcotc]

Done, thank you @delner!

[delner]

👍