Separate config validation from FileSystemConfigPersistence

[cgardens]

What

• When we started working on a PostgresConfigPersistence we noticed that were were duplicate the code for validating the schema of configs.

How

• Instead of doing that duplication, this PR creates a new class ValidatingConfigPersistence that will decorate any ConfigPersistence with the validation logic.
• Rename DefaultConfigPersistence => FileSystemConfigPersistence (in preparation of us having a PostgresConfigPersistence
• Change usages in ServerApp and SchedulerApp to use the decorated-with-validation version of FileSystemConfigPersistence.
• Hopefully this makes the next step of adding PostgresConfigPersistence a bit easier.

Other...

Instead of going with the decorator pattern here we could have these class extend a ValidatingConfigPersistence base instead. I'm open to that as well. In watching @subodh1810 deal with some of the validation stuff getting in the way that being able to interact with these persistences without opinionated validation might be helpful. I might be misguided on this though.

Recommended reading order

1. FileSystemConfigPersistence.java
2. ValidatingConfigPersistence.java
3. the rest...

@tuliren tagged you since this will interact with the issue you are going to work in.

[tuliren]

Thanks for tagging me on this.

In watching @subodh1810 deal with some of the validation stuff getting in the way that being able to interact with these persistences without opinionated validation might be helpful.

Yes, I think that we can sometimes mess up the migration such that user's old config becomes invalid. So a pure persistence may be helpful in some cases. But that should be an easy change.

[cgardens]

Will merge this this afternoon. Need to get one more test passing.

RunMigrationTest > testRunMigration() FAILED