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.

[alexander-yevsyukov]

LGTM

[codecov]

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

@@             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