Start making each FormatterStep roundtrip serializable.

[nedtwigg]

I don't like the design of the Gradle configuration cache. It puts too much burden on plugin developers, and it's too slow for end users (#987). But our workaround is a bit of a hassle, and we've had a really active contributor pool lately so maybe we have the brainpower to do the big rewrite that it would take to remove the JvmLocalCache workaround and fully support roundtrip serialization.

This PR introduces StepHarnessBase, which is a mechanism for enforcing that every individual formatter step must support roundtrip serialization. It will take a while for every step to support it, so we can adjust this StepHarnessBase as more and more steps add support. Once every step supports it, we will enforce this requirement for all new steps.

This PR also introduces FormatterStepEqualityOnStateSerialization. This allows us to keep the exact same equality semantics we have used so far, but it gives us more flexibility to implement serialization. Especially serialization of absolute paths without screwing up buildcache keys.

[nedtwigg]

@Goooler does this approach make sense? A nice thing is that we could merge these bit by bit, we don't have a hard fork situation, and once we have completed all of these we can remove JvmLocalCache and we'll have full native support for Gradle's configuration cache.

[jbduncan]

This PR looks fantastic! Let me know when you're close to the end and I'd be more than happy to give this a proper review.

[nedtwigg]

@jbduncan and @Goooler, a code review would be very welcome if you have time, thanks! In this PR I did

• the infrastructure
• applied the infrastructure to a simple step (Indent) and a typical step (Diktat).

I have also used this approach for some of our harder steps (eclipse), and I'm about to try the PipeStepPair too, which is one of the harder ones I think.

[jbduncan]

@nedtwigg It took me all evening to get my machine set up for Spotless again (fixing my vastly outdated fork on GitHub which was still using master, for instance), so I've not had a chance to review the code yet. Maybe next weekend!

[Goooler]

Use gh pr checkout 1945.

[jbduncan]

Thanks for the pointer, @Goooler! I've already fixed my fork and run git checkout serializable-refactor, but I'll consider gh for the future. 👍

[jbduncan]

Looking good, and I like the incremental approach to the new roundtrip serialization mechanism. A few things from me (see the review comments), but otherwise a fantastic start!

[nedtwigg]

Thanks very much for this thorough review! My plan is

• deploy main as-is (in progress)
• merge this and its follow-ons
• definitely allow breaking changes in lib
• hoping no breaking changes in plugin-maven or plugin-gradle, but TBD

Until we have complete switched over to configuration cache, I'd rather not publish any releases. That creates a bit of an awkward phase, but I think we can keep it down to just one or two weeks. Can always backtrack and make some kind of bugfix release branch if we have to.

[jbduncan]

LGTM! 👍