Order imports when reformatting

[pugnascotia]

Change the formatter config to sort / order imports, and reformat the codebase. We already had a config file for Eclipse users, so Spotless now uses that.

The "Eclipse Code Formatter" plugin ought to be able to use this file as well for import ordering, but in my experiments the results were poor. Instead, use IntelliJ's .editorconfig support to configure import ordering.

I've also added a config file for the formatter plugin.

Other changes:

• I've quietly enabled the toggleOnOff option for Spotless. It was already possible to disable formatting for sections using the markers for docs snippets, so enabling this option just accepts this reality and makes it possible via formatter:off and formatter:on without the restrictions around line length. It should still only be used as a very last resort and with good reason.
• I've removed mention of the paddedCell option from the contributing guide, since I haven't had to use that option for a very long time. I moved the docs to the spotless config.

[elasticmachine]

Pinging @elastic/es-delivery (Team:Delivery)

[mark-vieira]

FWIW I'm a bit on the fence on this one unless we can have this configured on import automatically. A lot of this manual IDE config stuff is missed by developers. If someone doesn't do this they are going to be in for a very frustrating time battling between IDE rules and spotless.

I'll quote David here:

yes sorting differently from IntelliJ would definitely be worse than today’s lack of sorting

We need to factor in that if this isn't configured automatically a non-negligible number of folks are going to hit this issue. I think having manual setup for things that are "optional" is fine, but I consider having import ordering rules match between the IDE and build be pretty much mandatory given that basically everyone uses this IDE feature.

[mark-vieira]

I think we can commit some stuff to .idea/codeStyles to declare a code style config with this stuff and have intelliJ automatically pick it up on import. We can then just ditch the codeStyle { } block in elasticsearch.ide.gradle.

[mark-vieira]

So yeah, let's set up the IDE import config the way we want, export it to a file in .idea/codeStyles and then edit .idea/codestyles/codeStyleConfig.xml to point to that config. I think that should do the trick.

[pugnascotia]

@mark-vieira I tried your suggestion but struggled to get it to work. I asked in the IntelliJ forums and someone suggested using a Settings Repository. Not mad keen on introducing something new - what do you think?

[mark-vieira]

Yeah, that is not gonna be a good solution given that code style is a project setting and settings repositories are for making all your IDE settings portable. I mean, we commit other stuff in the .idea folder, I feel like this should work. I wonder if we need to do something like we do for the Gradle JVM settings and modify the codeStyleConfig.xml config file on import vs check one into source control. I assume that's the issue? That the IDE is fighting with what we set there? I presume that just dropping a custom codestyle file in there get's picked up by IntelliJ just fine.

[pugnascotia]

So it turns out you can configure the imports order in IntelliJ via .editorconfig, so that's what I've done for Java and Groovy.

To see all supported properties, right-click a folder and select "New | EditorConfig File", check the IntelliJ IDEA-specific checkbox in the dialog that opens and, if needed, select the languages used in your project. An .editorconfig file will be generated with all IntelliJ-specific properties listed as comments.

[mark-vieira]

Brilliant 👍

[pugnascotia]

Backported to 7.x in fb8f84f