Concurrent safety and error handling

[stevenctl]

Bug report

Describe the bug

This is not a bug, but a feature request. I personally find stateful way ClientError is stored a bit strage.

(1) Consumption of func Xyz() (result, error) is much more natural for most Go callers.
(2) Modification to ClientError makes the client not concurrent-safe (along with modification to transport.header)

[stevenctl]

NewClient(), Rpc() and Ping() would be pretty easy to convert, or add RpcWithError variants (or a v2 struct).

A bit more effort would be required on FilterBuilder and QueryBuilder. Rather than storing the error on the client, we could store the error on the builder(s) themselves. Each of these ultimate seem to lead to calling Execute() which does return an error.

Doing this doesn't easily preserve the existing semantics. If a user relies on checking the error after buildng and before execute, we'd break them there is no reason we must stop setting ClientError other than breaking tests that set -race:

builder := client.Query().Collection("users").Filter("age", ">", 30).Insert(data)
if client.ClientError != nil {
    // handle error
}
_, err := builder.Execute()

[stevenctl]

#65 this helps with low-hanging fruit of the headers being mutex protected

[stevenctl]

#66 makes it so concurrent users can get errors from return values rather than shared mutable state

[muratmirgun]

Thanks for improvments 💯