Utxo crate cleanup

[azarovh]

Note: this PR is based on #333 which is not merged yet.

Decided to clean up a crate a bit before introducing any new changes. I think these changes will increase readability and make the code cleaner.

• Changed the layout of the crate
• Reworked pub declarations and use directives
• removed redundant dead_code and dead_imports with useless todos.

[TheQuantumPhysicist]

This looks mostly fine. Just a few things have to be thought through, especially the flags vs booleans thing. Booleans are a MUCH better solution than flags, but there's certainly solutions better than booleans, which we postponed for priority reasons. When I first read that you changed them to flags before looking into the PR, I was happy, because I thought we created some rusty solution that's type-safe... but it seems like we're back at C/C++ interface stuff with dangerously ambiguous non-type-safe solutions. We can certainly do better! If we don't want to do this now, then we better go back to booleans. At least booleans won't accept the value 0x56 at compile-time.

[iljakuklic]

This looks mostly fine. Just a few things have to be thought through, especially the flags vs booleans thing. Booleans are a MUCH better solution than flags, but there's certainly solutions better than booleans, which we postponed for priority reasons. When I first read that you changed them to flags before looking into the PR, I was happy, because I thought we created some rusty solution that's type-safe... but it seems like we're back at C/C++ interface stuff with dangerously ambiguous non-type-safe solutions. We can certainly do better! If we don't want to do this now, then we better go back to booleans. At least booleans won't accept the value 0x56 at compile-time.

I think a modest improvement over bools is a custom enum for each of these, like:

enum IsDirty { Yes, No }

Similarly for other bool-y things. These are all still basically bools but at least it's nicely explicit and it does not allow you to pass one in place of another without an explicit conversion of some sort.

[iljakuklic]

A couple of minor comments. Please address @TheQuantumPhysicist's comment on UtxosDBInMemoryImpl initialisation. Looks good otherwise

[TheQuantumPhysicist]

This looks mostly fine. Just a few things have to be thought through, especially the flags vs booleans thing. Booleans are a MUCH better solution than flags, but there's certainly solutions better than booleans, which we postponed for priority reasons. When I first read that you changed them to flags before looking into the PR, I was happy, because I thought we created some rusty solution that's type-safe... but it seems like we're back at C/C++ interface stuff with dangerously ambiguous non-type-safe solutions. We can certainly do better! If we don't want to do this now, then we better go back to booleans. At least booleans won't accept the value 0x56 at compile-time.

I think a modest improvement over bools is a custom enum for each of these, like:

enum IsDirty { Yes, No }

Similarly for other bool-y things. These are all still basically bools but at least it's nicely explicit and it does not allow you to pass one in place of another without an explicit conversion of some sort.

Like I mentioned in the daily, a type-safe flags, where we wrap u8 with a struct that has associated constant values is also OK from my end. So either that enum from Lukas or this type-safe flags thing. Whichever is fine for me.