Spike: Dynamic applying of an ideal linter configuration against new code

[fallwith]

Our existing rubocop.yml and .rubocop_todo.yml configurations along with our RuboCop version lock applied by newrelic_rpm.gemspec layer together to provide us with a stable linting platform that has very relaxed rules to accommodate our 15 year old code base.

Unfortunately this platform is incapable of automatically and objectively identifying problems with code that is newly introduced to the project via internal maintainer PRs. Code that would ordinarily violate 3 or so complexity rules or a max column count rule will either require a human reviewer to identify or float on through with a merge to pile on more tech debt.

I wonder what our options are for applying the most ideal configuration using the latest linter version against new code while still maintaining a relaxed and stable configuration for existing code.

Maybe we could run an ideal lint and cross-reference the problematic lines with the list of new or altered lines. Maybe a dedicated Action could be performed that doesn't impact the PR's status could be inspected by a reviewer.

For the purposes of this issue, an ideal linter configuration would be represented by the .rubocop.yml file itself. Currently, we have relaxations that were intended to be temporary that are stored in .rubocop.yml itself. Whether as a part of this issue or with a separate one, we should ultimately move all temporary rules out into .rubocop_todo.yml.

[workato-integration]

https://new-relic.atlassian.net/browse/NR-239006