Implement kernel and output features as enums

[antiochp]

Longer term we may want to consider being able to maintain the various feature specific data (lock heights for a height locked kernel, fee for coinbase kernel etc.) on the enum itself.
But to do this we would need to implement per enum type serialization and we would no longer be able to represent the enum as a simple u8.

This PR gets us 90% of the way there in terms of simplifying how we deal with features.

TODO -

• test serialization against floonet (nothing should change)
  • fast sync
  • broadcast (blocks and txs)

[tromp]

It is critical that we reject features outside the current range 0-2,
so we need to maintain the fallback clause
let valid_features = match features {
...
_ => false,

[antiochp]

@tromp Rust enums matching must be exhaustive (it won't compile otherwise). We don't need a fallback here because we have covered all the possibilities.

In fact if we try and add a fallback clause here then the rust compiler will complain -

warning: unreachable pattern                                                                                                                             
    --> core/src/core/transaction.rs:1382:3                                                                                                              
     |                                                                                                                                                   
1382 |         _ => false,                                                                                                                               
     |         ^                                                                                                                                         
     |                                                                                                                                                   
     = note: #[warn(unreachable_patterns)] on by default   

It is now impossible to construct a TxKernel with a KernelFeatures outside of the range 0-2.

[tromp]

Then what happens if the deserializer reads a value 3? Is that guaranteed to result in error?

[antiochp]

Then what happens if the deserializer reads a value 3? Is that guaranteed to result in error?

Yes we will catch this during deserialization here -

https://github.com/mimblewimble/grin/pull/2312/files#diff-404c77cf79ebda67cdbd58c1c99daa8cR63

KernelFeatures::from_u8(reader.read_u8()?).ok_or(ser::Error::CorruptedData)?;

Edit: let me add a test to demonstrate/verify this, so we have something to refer to in the code.

[tromp]

So the KernelFeatures::from_u8 throws an error given a value of 3?
I see you already added a test for that, so we're good...
Thanks!