Add on_kill method to BigQueryInsertJobOperator

[turbaszek]

Description

Add possibility to cancel running job if the operator is killed. This option probably should be cofigurable due to idempotency logic of the operator.

Use case / motivation

Remove dangling jobs.

Related Issues

#9590
#8858
#6470

[turbaszek]

@edejong @jaketf @potiuk I would love to hear your opinion on this one 👍

[jaketf]

I think this is straightforward for import / query / copy jobs as they are all internal to bigquery and committed atomically.

There may be a corner case with extract (to GCS) jobs. I do not believe export jobs > 1GB are atomic because the BigQuery export will write sharded GCS files. I imagine if killed at just the right time there would be just some portion of those sharded files committed to gcs.
Would our expected on_kill behavior be to clean up those files?
If we were to rerun the same export (with the same destination URIs in the config) those files would likely just be overwritten.
UNLESS the table has become much smaller or larger between the original (killed) try and the second try (causing the number of shards to change).

For example:
Original extract commits these files to GCS
shard-00-of-5
shard-01-of-5
[original extract job killed]
[we delete a few partitions from the source table]
[submit a new extract w/ same config]
shard-00-of-3
shard-01-of-3
shard-02-of-3

This will leave the GCS prefix looking like this:
shard-00-of-3
shard-00-of-5
shard-01-of-3
shard-00-of-5
shard-02-of-3

[turbaszek]

Thanks @jaketf for response! Do you think the edge case is something crucial to handle or should we see in the future if this causes problems?

@turbaszek
Since it's very similar to #10381, I created PR with this issue also, is that ok?

[turbaszek]

@tszerszen awesome! I will take a look

[turbaszek]

Closed in #10866