Better names and higher granularity for errors

[wprzytula]

Problem statement

There are quite a few places in driver's code where the errors' names and/or messages are inappropriate. Unjustified ProtocolError's usage is prevalent. We lack an error for faults triggered by user's logic, such as unwise custom RetryPolicy being used.

Proposed solution

Add more error variants (mainly for QueryError), fix the usaged to make names and messages appropriate. Stop abusing ProtocolError when no guilt is on received messages.

[roydahan]

What other drivers do for it and the question is if we need to conform into a practice that all drivers agreed upon?

[wprzytula]

What other drivers do for it and the question is if we need to conform into a practice that all drivers agreed upon?

With drivers, error handling depends strongly on the language used.

• Java driver uses exceptions (I suppose Python too);
• gocql uses err type together with various textual error messages;
• Cpp driver returns error code without any additional context;
• Rust driver has a hierarchy of enums that builds up a tree of error types; this could be described in some document (as I asked @muzarski for) and discussed about. In Rust driver, we want strongly typed errors to be able to pattern match on them.

What this issue is about is not making error handling in Rust driver "conformant" to other drivers (because there's no such convention whatsoever), yet it is about changes to the error types hierarchy to make it more reasonable.