Avoid `MIN_VALUE` and `MAX_VALUE` from `Timestamps`

[armiol]

This changeset addresses test code, which used easily-reached constants Timestamps.MIN_VALUE and Timestamps.MAX_VALUE.

The problem with using these constants is that on a Storage level, we convert those to nanoseconds — as it is a part of our mechanism on providing signal ordering within a single JVM (see emulated nanos in Time). But the mentioned constants defined by Timestamps cannot be converted to nanos, as the proposed Java type is long, and it is not long enough to store such values.

Ultimately, in Storage implementations, using these constants led to long overflow.

Besides, MIN_VALUE corresponds to 1 CE, and MAX_VALUE corresponds to year 9999. Both of which aren't widely used in event-sourced applications at the moment. We'll see how it goes, but for now it's definitely an overkill.

This PR migrates the test code to using more meaningful Timestamp values.

[armiol]

@alexander-yevsyukov PTAL.

[codecov[bot]]

Codecov Report

Merging #1544 (8967363) into master (e00ad8f) will increase coverage by 0.02%. The diff coverage is n/a.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #1544 +/- ## ============================================ + Coverage 89.81% 89.84% +0.02% Complexity 5025 5025 ============================================ Files 645 645 Lines 15751 15751 Branches 920 920 ============================================ + Hits 14147 14151 +4 + Misses 1276 1274 -2 + Partials 328 326 -2 ```