Use Case

See MONGOSH-1307. Adding validation to the Timestamp constructor would be a breaking change but it would be desirable to identify misconstructed timestamps.

User Impact

• Migration may requires code changes
  • Only users who have incorrectly built Timestamps would now be warned by the BSON library that there is an issue constructing the Timestamp instance

Acceptance Criteria

Implementation Requirements

• Assert the t and i fields are positive and within uint32.max

Testing Requirements

• The error would be thrown to a direct caller, or during deserialization
  • Test both cases

Remove two argument style ctor of Timestamp

• Migration will require code changes
  • Any instance of new Timestamp(low: number, high: number) will need to be wrapped in Long construction or broken into the i, t style constructor.

Acceptance Criteria

Implementation Requirements

• Remove support for the constructor overload that takes two plain numbers as input
• Since removing support will likely lead to a runtime error (props not existing etc.) add a helpful error to be thrown if this usage is detected.

Testing Requirements

• Assert the constructor fails in the old usage case
• Update any Timestamp tests to use the i, t style constructor