feat: update execute_query to use PrepareQuery API

[jackdingilian]

Update execute_query to use PrepareQuery for each request.

In there future there will also be an option to prepare once and reuse a PreparedStatement across requests. This updates the metadata to come from the PrepareResponse, but does so in a way that will be compatible with a future version that refreshes the PrepareResponse periodically (which can lead to schema change for e.g 'Select *' queries.

This also creates a sql_helpers test class and replaces old, more minimal, sql helpers in __testing

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes #<issue_number_goes_here> 🦕

[daniel-sanche]

Looks good overall. I added a couple small comments, and a question around retries

[daniel-sanche]

returning None seems fine, but have you considered raising an exception if this is called in the wrong state?

I could imagine arguments for either one, depending on the use-case

[jackdingilian]

I dont have a strong opinion between those options. Do you have a preference? or is there anything else like this in the client we should be consistent with?

[daniel-sanche]

I think I might have a slight preference towards an exception, because then we can attach a message explaining why it's empty. and it makes the types stronger, since we can avoid Optionals.

But I'm fine with either way, and it probably comes down to the context we expect people to use it in

(We have precedent for raising exceptions for something like this in firestore, but I can't think of any for bigtable)

[jackdingilian]

Sounds good. Updated it to raise an exception

[daniel-sanche]

are there any new system tests that can be added? Maybe using the new prepare_* arguments? Or accessing iterator.metadata?

[jackdingilian]

I want to add at least one against a real table, and I want to refactor the Metadata to expose the fields in ProtoMetadata. I was planning both of those for a follow on if that's ok (still to the branch before we merge).

For prepare_* it's a bit tricky since those are all retry/timeout params

[daniel-sanche]

LGTM