Insert of document via subdoc incorrectly returns EExists instead of NotStored if key already present

As found when investigating MB-50425, the subdoc Add flag will incorrectly return the status code EExists (0x2) if a document is found to already exist in the "read" phase of the "read-modify-write" subdoc execution process.

This is inconsistent with (a) the "wholedoc" ADD operation, and (b) with the status returned by the bucket when it performs the final atomic check on the given key (in the "write" subdoc execution phase). In both of these cases the status code NotStored (0x5).

This is problematic for a couple of reasons, but (b) above is arguably the larger problem - a developer could write an application using the Subdoc API and during testing (where there is little or no concurrency) would always see EExists returned, and assume that was status code seen when a document already exists. However when they go into production where there is greater concurrency, they could intermittently observe NotStored instead.

This has been the case ever since subdocument Add was introduced in v5.0.0 - see MB-23522.

While this is indeed a bug, we need to be careful addressing it, as "fixing" it could in theory make customers applications break; if they were only checking for the one of the above status codes EExists. While their applications are arguably buggy in this case, it could still manifest as an unexpected code for their app.