Change shell 'config' command to display sorted output

[foster33]

Fixes #2149

Fixes the bug where the config command inside the accumulo shell returns the properties unordered by using ImmutableSortedMap.copyOf.

There is only one instance that the shell output is directly effected by this so the other TreeMaps that were replaced I left alone and did not want to import additional things if it was not needed.

If there are other spots in the commit 4ea9bf1 that would directly benefit from the ImmutableSortedMap.copyOf change, I can make those changes as well.

[foster33]

I noticed that there were two parts in the previously linked commit, in Admin.java where TreeMaps were replaced in printNameSpaceConfiguration and printTableConfiguration . I am not sure where these would be printed but maybe these would benefit from a change.

[DomGarguilo]

Looks like the change from 4ea9bf1 in TableOperationsHelperTest.check() may benefit from being changed back to treemap since there is a comparison to a treemap.

[Manno15]

From my testing, Admin.java is fine as is. I tested both with and without the change and received the same results from the dumpConfig command.

[EdColeman]

@Manno15 - can you explain why the results would be the same? Looking at the dump configuration command implementation there does not seem to be any sorting - could it be just an accident that they matched and with either different values or values created in a different order that they would differ? It seems safest to assume that where a TreeMap was used there might be underlying code somewhere that was built using that assumption - unless it can be determined that is not the case.

[Manno15]

@EdColeman I figured out where my confusion came from. I should have paid closer attention, the printTableConfiguration checks first to make sure it is a table property. Therefore, the entire file was correct in that everything was ordered by table (the format for dump config is different than the regular config command. It follows the format config -t accumulo.metadata -s table.split.threshold=64M). Everything after the -s wasn't in sorted order as it was in older versions.

@foster33 So yes, both of those print functions should have the same change as the ConfigCommand, my mistake on not catching that earlier.

[ctubbsii]

There were a few places where #2122 changed the TreeMap to a non-sorted Map:

1. NamespaceOperationsHelper - this is only used for looping to update another data structure, and the order doesn't matter, so this is fine
2. TableOperationsHelper - same as NamespaceOperationsHelper; order doesn't matter, so this is fine
3. TableOperationsHelperTest - does not matter, because the map equality assertion it is checking will succeed whether or not the map is sorted (it only matters that the maps contain the same mapping, regardless of order)
4. Admin class - this one matters for presentation; both printTableConfiguration and printNamespaceConfiguration should use the ImmutableSortedMap.copyOf, to ensure the order is preserved
5. ConfigCommand - this one matters for the shell

[ctubbsii]

Looks good, but the TableOperationsHelperTest change isn't necessary, and it's best to avoid Guava when possible (fewer uses of Guava means fewer potential conflicts later).