Refactor command validation using ValidatableCommandClause

[amorton]

This builds on https://github.com/stargate/data-api/pull/1309

problems:

• we need to be able to validate a command, such as findOne, against a table or a collection
• we have validation code in multiple places, e.g. some is in SortClauseDeserializer some is in clauses like FilterClause
• we do not have a clear place in the architecture where we can say this is where the command and all it's clauses are valid, an error from here is in the execution of the request.

This ticket is to take the idea of the ValidatableCommandClause and:

• Make the Command interface extend ValidatableCommandClause, so all commands a validatable (maybe rename to Validatable if that makes sense)
• Implement the interface on each clause
• Have the command cascade down the validation to each clause it has.
• Call to validate from in the CommandProcessor call maybeValidate() on the command it get and handle any error before doing anything else.

Review all of the validation in different places and move as much as possible to be part of the ValidatableCommandClause process.

there may be some validation that does not make sense, or is hard to do, but we will address those as needed and make exceptions.

Thinking this should cover cases such as:

• Collection
  • Too many filter terms
  • Sort not correct, currently in SortClauseDeserializer
  • Projection invalid
  • Tables
  • inserting columns that do not exist on the table.
  • filtering on columns that do not exist

Additional thoughts:

• we are validating the request as sent by the user, it should only touch classes in the API tier
• This will also impact testing for the commands and clauses, i.e. it should hopefully be easier if we know all the validation errors should happen when we call maybeValidate on a SortClause. We should change / refactor the tests as we go.
• start by adding the validation to the Command and Clause classes for the API, if /when that gets messy we can think about refactoring out validation to another class(s)
• Knowing that the request has been validated like this before we start processing it may mean we want to change some things later in the processing, for example: if we know for an insert on a table all the fields in the doc are columns in the table, should we use the ColumnMetadata objects from the driver to talk about the column or continue with a String / CqlIdentifier. Spin up other tickets to address those so we can get all the validation in one place.

It probably makes sense to split other tickets off this for each clause, e.g. one for Sort one for Filter so this work is easier to commit.

[tatu-at-datastax]

I am not sure centralization, or -- in particular -- separation of validation step makes sense for all clauses. Many things are best validated when being processed: conversion from one representation (JSON) into another (Java objects) is the natural place to catch some (not necessarily all) problems. Trying to centralize all aspects may be lots of busy work. I guess additional optional step of validation, after conversions, might make sense.

But is that a cross-cutting concern with a single interface? And the only difference being whether command is for Collection or Table? I'll try re-reading #1309 to make sense of this issue.

[amorton]

This was not a good plan, better plan is what we ended up with. Get the user request, and validate it as part of making the internal representation