refactor(proto)!: remove proto timestamp wrapper types

[brianp]

Description

We were making use of 3 proto wrapper types. These types deserialize into option types and in some cases are not what we want.

This PR will update 2 of these types, while saving the third for an additional PR.

Motivation and Context

Use standard rust types, instead of library specific types.

Closes: #5797

How Has This Been Tested?

CI

What process can a PR reviewer use to test or verify this change?

Pay close attention to changes around timestamps. Could get tricky.
Notably, we were using Some(0) in some tests for timestamps. This was a valid timestamp for us, because it wasn't None. Now we're treating 0 as an invalid timestamp. So any test with None became 0 but tests with Some(0) are presumably tests that should have had valid timestamps but this was the easiest minimal value that was accepted.

Breaking Changes

• None
• Requires data directory on base node to be deleted
• Requires hard fork
• Other - Please specify

Messages between new and old nodes are likely to break.

[github-actions]

Test Results (CI)

1 232 tests   1 232 ✔️  13m 19s ⏱️
     39 suites         0 💤
       1 files           0 ❌

Results for commit e199048.

♻️ This comment has been updated with latest results.

[github-actions]

Test Results (Integration tests)

  2 files  11 suites   12m 56s ⏱️
33 tests 32 ✔️ 0 💤 1 ❌
34 runs  33 ✔️ 0 💤 1 ❌

For more details on these failures, see this check.

Results for commit e199048.

♻️ This comment has been updated with latest results.

[brianp]

I marked this controversial. Obviously, there are some tests to fix up, but having done the work I'm not sure I like the PR. It feels like we've taken a strongly typed paradigm such as having a new block tip, or not, and allowed the chance for defaults like a 0 filled vec take it's place, creating a vaguely strongly typed paradigm.

It's not an all or nothing though in the case of timestamps a forced u64 can often make sense. What we're losing is having null types in the database and instead, as a default will always land us in 1970.

In the case of one function we expected a timestamp relatively close to the current date, and skipped it if None. If we default to 0 we would end up querying everything in the table. As the default would be 1970 and we would query everything since 1970. So there's always the chance a default date can land us somewhere we don't want.

Alas, these are just thoughts. I'll continue on, and see if anyone else holds an opinion.

Edit: I forgot to add a recommendation. I think getting rid of the protobuf wrappers is still a good idea. But it may be beneficial if we manually map the proto message from its value default or otherwise, into an Option again. This would leave almost all the code exactly the same other than some minor adjustments in the serializers/deserializers.

[brianp]

Update on my previous comment: More or less what I had written in the recommendation was what some others had in mind. This PR has been updated to reflect that. So the changes are only in the proto types, and serialization/deserialization where needed. Tari types shouldn't need to change here.

[SWvheerden]

Looks good, just the one we need accept and cannot error on. I think its find that we just accept a 0 zero