refactor(NODE-3402): implement MongoAPIError and its children

[W-A-James]

Description

Implement the errors detailed in docs/errors.md from NODE-3363 that fall under MongoAPIError

What changed?
Replacing MongoDriverError instances with the following errors where appropriate

• MongoInvalidArgumentError
• MongoMissingDependencyError
• MongoMissingCredentialsError
• MongoCompatibilityError

[W-A-James]

Currently going back through the driver to locate anywhere I may have missed that would benefit from a child instance of MongoAPIError in place of MongoDriverError

[andymina]

src/bulk/common.ts:1150: I think it might be worth to make this MongoInvalidArgumentError.

[andymina]

src/cmap/auth/scram.ts:31: This should be MongoMissingCredentialsError.

[andymina]

src/cmap/commands.ts:85: I'm not quite sure how I feel about this being MongoInvalidArgumentError. I feel like MongoURIError might be a little more fitting here since the string to be parsed has an invalid char. Happy to defer to the rest of team.

[andymina]

src/cmap/commands.ts:855: Although realistically we shouldn't run into this error, I think it'd be good practice to replace this with MongoCompatibilityError since it was decided that no drivers would make use of payload type 1.

Update: Originally, I thought MongoCompatibilityError would fit here, but because of Eric's reasoning I think MongoDeprecationError is better here.

[andymina]

src/cmap/connection.ts:661: This should be MongoCompatabilityError.

[W-A-James]

src/cmap/commands.ts:85: I'm not quite sure how I feel about this being MongoInvalidArgumentError. I feel like MongoURIError might be a little more fitting here since the string to be parsed has an invalid char. Happy to defer to the rest of them.

@andymina
I think it might be worth keeping MongoParseError since in instances like this, we're not doing anything with the URI string itself, but rather just parsing a namespace string (<database>.<collection>)

[andymina]

src/cmap/commands.ts:85: I'm not quite sure how I feel about this being MongoInvalidArgumentError. I feel like MongoURIError might be a little more fitting here since the string to be parsed has an invalid char. Happy to defer to the rest of team.

@andymina
I think it might be worth keeping MongoParseError since in instances like this, we're not doing anything with the URI string itself, but rather just parsing a namespace string (<database>.<collection>)

@W-A-James
From the description of MongoURIError that we've got in docs/errors.md, I think this use case should be covered by it. Although if you think it's worth to split the two and reintroduce MongoParseError, I'm down.

[andymina]

src/cmap/connection.ts:651: This should MongoMissingDependencyError per NODE-3363.

[andymina]

src/encrypter.ts:29: Should this also be MongoInvalidArgumentError?

[andymina]

I think once the changes requested in the comments are resolved, LGTM.

[W-A-James]

src/cmap/commands.ts:85: I'm not quite sure how I feel about this being MongoInvalidArgumentError. I feel like MongoURIError might be a little more fitting here since the string to be parsed has an invalid char. Happy to defer to the rest of team.

@andymina
I think it might be worth keeping MongoParseError since in instances like this, we're not doing anything with the URI string itself, but rather just parsing a namespace string (<database>.<collection>)

@W-A-James
From the description of MongoURIError that we've got in docs/errors.md, I think this use case should be covered by it. Although if you think it's worth to split the two and reintroduce MongoParseError, I'm down.

@andymina
From the description we have for MongoURIError, namespaces, outside the context of connecting to the server itself, seem like they come up enough to justify having MongoParseError continue to be a separate error. There are other cases (src/cmap/message_stream.ts: 138, 144 & src/sdam/topology.ts: 279) where MongoParseError fits better than MongoURIError in my opinion, so my vote is to keep MongoParseError and add it to our hierarchy alongside MongoURIError

[andymina]

src/cmap/commands.ts:85: I'm not quite sure how I feel about this being MongoInvalidArgumentError. I feel like MongoURIError might be a little more fitting here since the string to be parsed has an invalid char. Happy to defer to the rest of team.

@andymina
I think it might be worth keeping MongoParseError since in instances like this, we're not doing anything with the URI string itself, but rather just parsing a namespace string (<database>.<collection>)

@W-A-James
From the description of MongoURIError that we've got in docs/errors.md, I think this use case should be covered by it. Although if you think it's worth to split the two and reintroduce MongoParseError, I'm down.

@andymina
From the description we have for MongoURIError, namespaces, outside the context of connecting to the server itself, seem like they come up enough to justify having MongoParseError continue to be a separate error. There are other cases (src/cmap/message_stream.ts: 138, 144 & src/sdam/topology.ts: 279) where MongoParseError fits better than MongoURIError in my opinion, so my vote is to keep MongoParseError and add it to our hierarchy alongside MongoURIError

@W-A-James SGTM, lets see what the rest of the team thinks because this would likely cause another PR to 4.0 to update the doc

[andymina]

LGTM, nice job

[dariakp]

LGTM, keep up the great work!