feat(NODE-4770)!: remove 12 length string support from ObjectId constructor

[nbbeeken]

Description

What is changing?

• Removing the ability to pass a string that reports a length of 12 from creating an ObjectId
• Updating the .equals method to correspond

Is there new documentation needed for these changes?

The usage was never reported by the API prior and worked inconsistently, 12 length strings interpreted as utf8 / iso88591 interchangeably. I think this release note serves as enough documentation.

What is the motivation for this change?

See notes, and doc section.

Release Highlight

Strings of length 12 can no longer make an ObjectId

(From String.length): [The String length] property returns the number of code units in the string. JavaScript uses UTF-16 encoding, where each Unicode character may be encoded as one or two code units, so it's possible for the value returned by length to not match the actual number of Unicode characters in the string.

The ObjectId constructor erroneously interpreted a string with length of 12 as UTF8 bytes that could be converted to an ObjectId. This is unexpected for at least two reasons. The first is that a legacy approach (pre- Uint8Arrays) to handling binary data was to pass around "binary strings", where each character represents a single byte, this is not the same as interpreting a sting as UTF8, which has restrictions on how each byte can be formatted. The second is that a string of length 12 does not result in 12 bytes of data when converted to utf8 (ex. '🐶🐶🐶🐶🐶🐶'.length === 12, but as UTF8 bytes this is a 24-byte sequence).

Despite the bugginess of the behavior discussed above, the right string in the right context does create the proper byte sequence, so we are considering this a breaking change and removing it in this major release.

Double check the following

• Ran npm run check:lint script
• Self-review completed using the steps outlined here
• PR title follows the correct format: type(NODE-xxxx)[!]: description
  • Example: feat(NODE-1234)!: rewriting everything in coffeescript
• Changes are covered by tests
• New TODOs have a related JIRA ticket

[W-A-James]

Also, if you could put the dependency changes in the ticket AC, that would be great.