[#2674] fix(jdbc backend): Save millisecond timestamp on mysql soft delete

[xloya]

What changes were proposed in this pull request?

The current way of saving second-level timestamps will cause multiple deletion operations fails in the same second because of the duplicate key. This pr will save millisecond timestamp.

Why are the changes needed?

Fix: #2674

[xloya]

@yuqi1129 Could you help test this is worked in integration tests? Thanks.

[yuqi1129]

@xloya
it works for MetalakeIT, what concerns me is whether this is the right way to solve the problem. Milliseconds are sufficient for most cases, but can we use a larger value to completely avoid the problem?

like current_milliseconds << 18 + auto_increment_value_within_2^17

[xloya]

@yuqi1129 I agree that enlarging the value avoids the problem as much as possible.
I have seen some implementations of soft deletion. Some use the Datetime type, which has second-level precision; some use the Timestamp type, which has microsecond-level precision. I haven't seen any implementation of soft deletion using higher precision yet. Maybe a timestamp at the millisecond or microsecond level is enough.
In addition, we need to consider whether multiple databases support the same time function. The current implementation has considered the compatibility of H2 and MySQL time functions. I am not sure if there is a function that can implement the logic you mentioned.

[yuqi1129]

LGTM