0012_Adapt memcached error code handling for future proofing

[ingenthr]

I believe the current behavior for all issues other than TMPFAIL is to pass them back to the application layer.

In some scenarios where the bucket isn't available yet and things like MB-13156, MB-12088/MB-14442 it's been suggested that clients should retry on all unknown errors.

Possible ideas are to come up with ranges for errors to know in advance what to retry and what to bubble up to the developer or just develop defaults.

[mnunberg]

You mean "other than NOT_MY_VBUCKET". TMPFAIL is passed back to the application.

Libcouchbase already has a concept of "error categories", and indeed Memcached can add additional bits to the end of error codes to indicate what type they are. Memcached has 16 bits reserved for errors, but in practice I only see the first 8-10 actually being used.\

In general I think it's important that Couchbase and Memcached establish a "baseline" understanding of current error codes.. in the specific case of NO_BUCKET or AUTH_ERROR, unless the SDK instructs memcached that it is aware of these special errors and can retry them while maintaining the current connection, the behavior should be to drop the connection. This indication of readiness can be negotiated via the HELLO command.

If there are new error codes, Memcached can report the raw error if the SDK has negotiated "understanding" of this error.

Otherwise (if the SDK did not indicate it understands that error) it may "fold" the error into something less destructive (if the error is only informative and transient) or close the connection (if the error is fatal and pertains to the connection state as a whole).