feat: reject invalid timestamp ranges in copy statement

[v0y4g3r]

I hereby agree to the terms of the GreptimeDB CLA.

Refer to a related PR or issue link (optional)

What's changed and what's your intention?

This PR adds timestamp validity check to reject invalid timestamps in copy statement.

mysql> copy monitor from '/tmp/export/monitor.parquet' with (format='parquet', START_TIME='2023-12-13 03:05:41', END_TIME='2023-12-13 02:05:51');

ERROR 1815 (HY000): Invalid timestamp range, start: `2023-12-13 03:05:41+0000`, end: `2023-12-13 02:05:51+0000`

Checklist

• I have written the necessary rustdoc comments.
• I have added the necessary unit tests and integration tests.
• This PR does not require documentation updates.

[codecov]

Codecov Report

Attention: Patch coverage is 96.00000% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 85.02%. Comparing base (bfd3257) to head (e3d1987).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3623      +/-   ##
==========================================
- Coverage   85.35%   85.02%   -0.33%     
==========================================
  Files         932      932              
  Lines      155611   155620       +9     
==========================================
- Hits       132818   132313     -505     
- Misses      22793    23307     +514     

[tisonkun]

Thanks for this prompt fix.

1. This patch should be "fix" or "feat" rather than "chore".
2. Perhaps we can lower the Option -> Result into GenericRange::new method? All other refs seems in the test scope.

[v0y4g3r]

1. This patch should be "fix" or "feat" rather than "chore".

Fixed.

2. Perhaps we can lower the Option -> Result into GenericRange::new method? All other refs seems in the test scope.

GenericRange::new does not have other error variants and it does not know how to interpret T in it's error message.

[evenyag]

Rest LGTM

[tisonkun]

Thanks for your updates and explanation! LGTM.