Add BigQuery job link

[nakamura1878]

This pull request introduces a new helper class for constructing BigQuery Job Detail Links and integrates it into the existing BigQuery operators and links in the Google Cloud provider for Airflow. The most important changes include the addition of the BigQueryJobDetailLink class, its integration into the BigQueryInsertJobOperator, and the necessary imports and configurations.

New feature addition:

• Added BIGQUERY_JOB_DETAIL_LINK constant to construct URLs for BigQuery Job Detail Links in airflow/providers/google/cloud/links/bigquery.py.
• Created BigQueryJobDetailLink class to handle the construction and persistence of BigQuery Job Detail Links in airflow/providers/google/cloud/links/bigquery.py.

Integration into existing operators:

• Imported BigQueryJobDetailLink in airflow/providers/google/cloud/operators/bigquery.py to make it available for use in BigQuery operators.
• Updated operator_extra_links in BigQueryInsertJobOperator to include BigQueryJobDetailLink in airflow/providers/google/cloud/operators/bigquery.py.
• Added logic to persist BigQuery Job Detail Links in the execute method of BigQueryInsertJobOperator in airflow/providers/google/cloud/operators/bigquery.py.

Configuration update:

• Added BigQueryJobDetailLink to the extra-links section in airflow/providers/google/provider.yaml to ensure it is recognized as an extra link.

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our pre-commits will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[shahar1]

Welcome to Apache Airflow and thank you for your first contribution!
Overall LGTM, I've got a small question though :)

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.

[shahar1]

@nakamura1878 Woops, only now I noticed that this PR was targeted at v2-10-test - PRs for providers should target the main branch.
I'll take care of reverting this PR on v2-10-test and porting it to main.

[potiuk]

@nakamura1878 Woops, only now I noticed that this PR was targeted at v2-10-test - PRs for providers should target the main branch.
I'll take care of reverting this PR on v2-10-test and porting it to main.

Yep - we could do it, but we could also bring it to main (forward-port :) ) without reverting - there is no big harm in getting it in.

[jscheffl]

I also just noticed it was on the "wrong" branch - but only because I had a test on v2-10-test running that was cancelled due to the merge.

[shahar1]

I also just noticed it was on the "wrong" branch - but only because I had a test on v2-10-test running that was cancelled due to the merge.

Apologies for that :)
@potiuk fair enough. Is there any stance about removing the providers from v2-10-test to avoid such confusion? I assume that it hasn't been done until now for a reason, not sure what though considering that we continue maintaining them in main.

[jscheffl]

I also just noticed it was on the "wrong" branch - but only because I had a test on v2-10-test running that was cancelled due to the merge.

Apologies for that :) @potiuk fair enough. Is there any stance about removing the providers from v2-10-test to avoid such confusion? I assume that it hasn't been done until now for a reason, not sure what though considering that we continue maintaining them in main.

No we just keep them here. Would be "too much" cleanup and CI has still a lot of dependencies and cross-checks.

[potiuk]

I also just noticed it was on the "wrong" branch - but only because I had a test on v2-10-test running that was cancelled due to the merge.

Apologies for that :) @potiuk fair enough. Is there any stance about removing the providers from v2-10-test to avoid such confusion? I assume that it hasn't been done until now for a reason, not sure what though considering that we continue maintaining them in main.

No we just keep them here. Would be "too much" cleanup and CI has still a lot of dependencies and cross-checks.

Actually it could be possible eventually. We have been removing all the "remnants" of provider tests from CI and I think with some future refactoring of providers into separate projects (working on it) - it could be possible eventually. I might attempt it as part of #42632 and after #44511 is completed.

For now the remaining parts are:

• "airflow" contains some tests that are expecting providers (executors and few others) as mentioned by @jscheffl
• airflow "editable" build expects the "extras" to use provider's dependencies not providers itself (but that could be likely mitigated easily - and we could use the "released" providers in v2-10-test

It's actually quite likely that for Airflow 3 we will have "non-providers" code only in v3-0-test.