Fix bug where nested MissingBraces violations' suggested fixes result in broken code

[keithl-stripe]

@holtherndon-stripe came across this issue while applying MissingBraces to Stripe's code base of 4 million lines of Java code.

See unit test for sample code.

I'm not sure about a few things:

• Why does the coalescing code suppress duplicate inserts? It seems a bit odd that this is the default. I wonder which checkers' fixes need this, and why.
• Is Fix the right level of abstraction? Or should the coalescing policy be per Replacement?

[cpovirk]

I don't know enough to offer a definite way forward here, but I happen to know a couple relevant pieces of information:

• I imagine that a large number of checkers depend on deduplication. That's not to say that it's a great idea for them to do so, but it can be convenient :) For example, I wrote a checker that looks for return null and recommends inserting @Nullable on the enclosing method. It sometimes finds methods that contain return null more than once, in which case it outputs duplicate suggestions.
• I recall that we had a problem very similar to the one you're reporting but with MustBeClosedChecker. We added some code to manually insert n closing braces as a single postFix with call, and then we were able to rip it out for reasons that I'm not actually clear on. I don't know if that's evidence that we should support a proper fix (like you're proposing), evidence that we'd rather hack around it, or evidence that there's actually some superior way of doing it that I'm unaware of.

Actual core Error Prone team members may have more useful advice.

[cushon]

• I imagine that a large number of checkers depend on deduplication. That's not to say that it's a great idea for them to do so, but it can be convenient :) For example, I wrote a checker that looks for return null and recommends inserting @Nullable on the enclosing method. It sometimes finds methods that contain return null more than once, in which case it outputs duplicate suggestions.

I had a quick look at whether we could 'just' preserve duplicate inserts by default. ReturnMissingNullable was one example I ran into, there were a couple of others that similarly emitted the same method-level fix once per occurrence of a problem int he method body, leading to things like duplicate @SuppressWarnings annotations, or duplicate exceptions in throws, etc.

• I recall that we had a problem very similar to the one you're reporting but with MustBeClosedChecker. We added some code to manually insert n closing braces as a single postFix with call, and then we were able to rip it out for reasons that I'm not actually clear on. I don't know if that's evidence that we should support a proper fix (like you're proposing), evidence that we'd rather hack around it, or evidence that there's actually some superior way of doing it that I'm unaware of.

I think part of what happened with MustBeClosedChecker was that the DuplicateInsertPolicy stuff got added, and that was configured when using MustBeClosedChecker as a refactoring tool.

I suspect we're not done play whack-a-mole with edge cases involving overlapping and adjacent fixes, but I also think allowing MissingBraces to opt-in to this is an improvement over the status quo.