Add IntelliJ formatter

[peternied]

Description

Adds an IntelliJ native formatter based off the eclipse formatter that also supports import ordering.

Testing

Manually verified the Optimize Imports output does not alter existing files on all classes under DocumentsFromSnapshotMigration/src/test/java/com/rfs/

Check List

• New functionality includes testing
  • All tests pass, including unit test, integration test and doctest
• New functionality has been documented
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[AndreKurait]

Do we want to add this in a .idea to pre-configure it?

[peternied]

I don't know how to do that, but that sounds like a great follow up PR - want to take that on?

[gregschohn]

Thanks for doing this... one question on the import ordering that seems overly prescriptive.

[gregschohn]

Why are these called out separately? Why are there two places that I have to check for 3rd party imports? I can understand keeping migrations/opensearch things in one block and java stuff in another. Beyond that, it seems like everything is on equal standing.

[peternied]

This list is derived from the existing spotless rules, lets handle that out of band of this change. For intellij-formatter.xml was generated by exporting the settings from IntelliJ rather than edited by hand.

[peternied]

@gregschohn What would you like to do with this PR. I do not have much in investing more into this change, just want to get something out there to unblock folks. I think it would be useful to merge as is and folks such as yourself could refine the formatter settings. If you don't think so I'd rather close this out. What do you think?

[gregschohn]

@gregschohn What would you like to do with this PR. I do not have much in investing more into this change, just want to get something out there to unblock folks. I think it would be useful to merge as is and folks such as yourself could refine the formatter settings. If you don't think so I'd rather close this out. What do you think?

I just ran spotless on an RFS directory and got this back...

package com.rfs.common;

import java.nio.charset.StandardCharsets;
import java.util.Comparator;
import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;

import io.opentelemetry.sdk.trace.data.SpanData;
import org.hamcrest.MatcherAssert;
import org.hamcrest.Matchers;
import org.junit.jupiter.api.Test;

import org.opensearch.migrations.snapshot.creation.tracing.SnapshotTestContext;
import org.opensearch.migrations.testutils.HttpRequestFirstLine;
import org.opensearch.migrations.testutils.SimpleHttpResponse;
import org.opensearch.migrations.testutils.SimpleNettyHttpServer;

import com.rfs.tracing.RfsContexts;
import reactor.netty.http.client.HttpClient;
import reactor.netty.resources.ConnectionProvider;

The fact that we're currently splitting our own implementations into two groups (notice that com.rfs is still the package namespace for lots of RFS code). Furthermore, the reactor imports are separate from hamcrest and otel, which doesn't make sense to me. With this change, we'll have 3 versions of files that we need to fix up going forward. I'd rather find out what rules we want & push them all out in a unified format, otherwise, the tax of tweaks is tripled.

[peternied]

@gregschohn I'm going to close out this PR - it doesn't seem to be helping and I don't plan on spending more cycles here. Feel free to pick it up or make another PR for that changes you'd like to see.