chore: update comments and tests for label counts.

[Genesis929]

1. Renamed add_labels to add_and_trim_labels.
2. Added notes and docstring for future notification.
3. Added tests for add_and_trim_labels and the functions that calls add_and_trim_labels to ensure the total number of labels won't exceed 64.

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> 🦕

[shobsi]

The repetition of this note at multiple places makes me think - can we not call start_query_with_client instead of bqclient.query from everywhere? That way any preprocessing (including labels) would be centralized and we would have only one note lilke this in our code.

[Genesis929]

The logic after bqclient.query in start_query_with_client don't seems to match other functions, so this may not work.

We can make a new function that add labels and execute to replace bqclient.query, what do you think? This is my original thought but I'm not sure if it's necessary to add a new function just for two lines of code.

[shobsi]

Not a great refactoring but better than leaving repetitive notes IMHO.

[shobsi]

Or we could make a hook in the ClientsProvider._create_bigquery_client, something like:

...
original_query = bq_client.query

def query (query, *args, job_config=None, api_name=None, **kwargs):
    add_and_trim_labels(job_config, api_name=api_name)
    original_query(query, *args, job_config=job_config, **kwargs)

bq_client.query = query
...
return bq_client

@tswast would this be too hacky? What would be the most pythonic way to ensure labels are within the max limit?

[tswast]

I would discourage us from monkey patching like this, though it should work in Python. I think your first instinct of using our central helper function makes the most sense to me.

I don't fully understand what you mean by

The logic after bqclient.query in start_query_with_client don't seems to match other functions, so this may not work.

We should be able to put start_query_with_client in a try/except block. Also, it's probably a bug that we aren't showing that a query job is running here.

[tswast]

I'm pretty sure result() is a no-op for dry-run.

[tswast]

I don't think we actually create a job resource in the backend when we do a dry-run, so this might actually lose analytics. I think probably better not to call add_and_trim_labels at all in this case.