chore: Refactor validator tx schema

[sergerad]

The validator currently stores overly large data in the DB that is not necessary.

Closes #1715.

[sergerad]

@bobbinth how do we decide on these points from #1715?

input note info (need to define what exactly gets stored)
output note info (need to define what exactly gets stored)
maybe some other metadata (e.g., initial account state hash, final account state hash, transaction fee).

[Mirko-von-Leipzig]

Code LGTM, but I'm also uncertain what we need to store for notes.

Maybe @PhilippGackstatter has some ideas? afaik the point isn't to be able to reconstruct the transaction, but just identify and know its details.

[Mirko-von-Leipzig]

afaik these can all be empty

• account delta can be empty for pass through txs, and
• no input notes, and
• no output notes

[Mirko-von-Leipzig]

Or is that fine as not null, and it will simply be an empty vector? cc @drahnr is Option::<Vec<u8>>::None and Vec<u8>::new() equivalent in sql/diesel land?

[bobbinth]

Yes, all of these could be null.

Regarding what to store for notes - ideally, we should store full note data (even for private notes). For input notes, I think this should be pretty straight forward (I believe input notes for a transaction are already full notes). For output notes, this would be tricky as we actually don't have full info available in some cases. But maybe that's OK as an output note would need to become an input note at some point.

So, maybe for this PR, we just make sure we store full input notes (i.e., Vec<InputNote>) and w/e we get from the executed transaction as output notes (i.e., Vec<OutputNote>).