Validate Compaction services work across upgrades

[ddanielr]

Is your feature request related to a problem? Please describe. The compaction properties have undergone many changes across the 2.1/3.1/elasticity branches. External compactions should be tested as a function of the upgrade job.

Items to consider

• Outdated dispatcher props left defined at the table level.
• Outdated compaction service props left defined.

Describe the solution you'd like Compaction services should function after an upgrade without issue.

[dlmarion]

I made a comment somewhere , but I can't find it right now. It was something that I thought of while working on #4289. The basic gist of the comment was that configuration properties that are defined outside of Property.java can't be validated. My proposal, for which I apparently didn't create a ticket for, was to create a base interface for all SPI interface classes. That base interface would have a method that would accept the configuration as a parameter and implementation should validate that the properties are correct.

I think one issue with this approach is that we don't know which SPI implementation are in use. We have PropertyType.CLASSNAME, but I'm not sure that in all cases the class is an SPI implementation. We could possibly create a PropertyType.SPI_IMPL type and then call the validate method on those classes. But I'm still not sure that this would catch all cases.

In any case, the scope of this problem is larger than described in this issue.