Allow implementing ExecutableQuery interface

[worryg0d]

The driver allows users to provide their implementations of HostSelectionPolicy. However, it contains Pick() method that requires an arg of the ExecutableQuery type. The ExecutableQuery interface can't be implemented outside the pkg because it consists of private methods such as execute(), attempt(), etc.
The driver should allow users to implement ExecutableQuery to allow them to test their custom implementations of anything that requires ExecutableQuery.

[joao-r-reis]

Ensure host selection policies can be implemented outside the package.

Why can't these policies be implemented outside the package at the moment?

[worryg0d]

As far as I remember they actually can, but we can't properly test them because there is Pick() method that requires an ExecutableQuery that can't be mocked because it consists of some private methods such as execute, attempt

[joao-r-reis]

Ok then we should change the title and description of the issue

[worryg0d]

Yes, it makes sense since it touches the implementation side, but it is misleading in understanding the problem. I changed the title and described in detail what the actual problem is.

[joao-r-reis]

Hmm with this title I don't think it's related to #1754 anymore is it?

[worryg0d]

I think so, it can be closed for now...

[martin-sucha]

There are also other options how to achieve testability of HostSelectionPolicy implementations outside of the gocql package.

If this gets changed in a major version, the HostSelectionPolicy.Pick could take another type instead of ExecutableQuery. Which information is actually useful for the HostSelectionPolicy implementation? For example SetConsistency(c Consistency) isn't necessary, while Attempts() is racy.

Also, passing a struct instead of interface would allow for new fields to be added in backwards compatible way without the users needing to type-check everything. By the way, is it possible to type cast the ExecutableQuery to *Query or *Batch now in the HostSelectionPolicy implementation?

Another option would be to provide a mock ExecutableQuery implementation directly in the gocql package.

[worryg0d]

passing a struct instead of interface would allow for new fields to be added in backwards compatible way without the users needing to type-check everything

It sounds like a good idea to me. It will allow us to append new useful info (if any) without any breaking changes. Also, it will enable users to easily test their implementations of HostSelectionPolicy without needing to mock the ExecutableQuery.

is it possible to type cast the ExecutableQuery to *Query or *Batch now in the HostSelectionPolicy implementation?

On the current codebase yes, it is.

[joao-r-reis]

By the way, is it possible to type cast the ExecutableQuery to *Query or *Batch now in the HostSelectionPolicy implementation?

This is also an issue for CASSGO-22, the current proposal (comment here) is to add a RetryableQuery interface (implemented by a new internal struct that is not immutable so we can make Query/Batch immutable) and add a GetQuery() method to RetryableQuery so get the original Query or Batch object if a custom retry policy needs to access it.

@martin-sucha can you provide feedback on that ticket (CASSGO-22)? It's potentially a significant change of the API so it would be nice to get as much feedback as possible. CASSGO-22 changes will impact what happens with this current issue as well. It would be great to improve this part of the API before the 2.0 release.