[WIP] Move protocol validation to TableConfiguration

[OussamaSaoudi]

What changes are proposed in this pull request?

This PR affects the following public APIs

How was this change tested?

[OussamaSaoudi]

@scovich @nicklan @zachschuermann
Hey folks, this is a draft PR that I intend to break up, but I wanted some thoughts on the ideas I was working on. In particular, I want opinions on:

Error Types

The introduction of InvalidTableConfigurationError and SupportError. I want to introduce better errors in kernel. This is both for testability and for clearly communicating errors to users.

On the testing side, I've already seen improvements in some of the CDF tests. We can now make far stronger assertions on why something fails. Examples: [1], [2]

On error communication: I've already seen one incident were a kernel user got an error that didn't explain why they couldn't run CDF on a table. Just that they couldn't. CDF error now explains why CDF is unsupported at that version.

The questions are:

1. Can/Should I use with this style of error handling?
2. Are you happy with the split of validity errors and support errors?

Debug Assertions

I want to start using more debug_assert s in the code, and want to hear your thoughts on how I've used them here.

try_new ensures that our table configuration is valid. I can assert that it continues to be valid in all the is_x_supported methods. Ex: [1].

I remember that panicing in kernel is especially rough due to FFI, so I'd like to see ways we can catch fatal errors through tracing as well.

Newtype pattern for TableConfiguration Semantics

I was experimenting with the NewType pattern to have type-level assertions on what a TableConfiguration supports. @zachschuermann had mentioned he didn't like the previous approach and floated the idea of using types. This is extremely easy with rust's Deref trait, and it avoids the weird semantics we had before where try_new checks both validity and support.

Here's where I used it for Transaction

Here's the one for Snapshot

TableProperty constants

aside: constants won't bind in match statements, so they're a great tool for matching on many strings.

let Y = "SOME CONSTANT";
match x {
    Y => /* Y here is not the same as Y up there */
}

vs

const Y = "SOME CONSTANT";
match x {
    Y => /* here we match on x being the string "SOME CONSTANT" */
}

[OussamaSaoudi]

Note: this is stacked on top of #645

How I plan to break the remaining stuff up:

1. Move protocol validation to table configuration
2. Create invalidTableConfig and support error types
3. add errors types to CDF error + all the refactoring involved with that
4. Newtypes for transaction/tableConfig (if folks think this is a good direction)
5. (possibly) encode table properties as an enum instead of the constant strings.