add optional service account for scheduled queries

[MartinNowak]

• https://cloud.google.com/bigquery/docs/release-notes#November_21_2019
• see Scheduling queries, parameter documented at Try API or Discovery
• the API does support PATCHing, but magic-modules doesn't really support setting
  the required update_mask for url_param_only, hence I marked this parameter as
  input for now (which will replace the resource on update)
• followup to add optional service account for scheduled queries #3347 (sorry for opening a new PR I renamed the branch)
  changes requested by slevenick are addressed and I ran terraform's acceptance test (TestAccBigqueryDataTransferConfig) and tested this manually w/ terraform

Release Note Template for Downstream PRs (will be copied)

* bigquery: added `service_account_name` field to `google_bigquery_data_transfer_config` resource

[modular-magician]

Hello! I am a robot who works on Magic Modules PRs.

I have detected that you are a community contributor, so your PR will be assigned to someone with a commit-bit on this repo for initial review.

Thanks for your contribution! A human will be with you soon.

@danawillow, please review this PR or find an appropriate assignee.

[modular-magician]

Hi! I'm the modular magician. Your PR generated some diffs in downstreams - here they are.

Diff report:

Terraform GA: Diff ( 3 files changed, 17 insertions(+), 2 deletions(-))
Terraform Beta: Diff ( 3 files changed, 17 insertions(+), 2 deletions(-))

[modular-magician]

Oops! It looks like you're using an unknown release-note type in your changelog entries:

• REPLACEME

Please only use the types listed in https://github.com/GoogleCloudPlatform/magic-modules/blob/master/.ci/RELEASE_NOTES_GUIDE.md.

[MartinNowak]

Let me know if I can do sth. to solve that Google Cloud Build error, can't see the logs unfortunately.

[danawillow]

This looks good to me. I added a changelog message and am rerunning cloud build, so that should be enough to resolve it.

I'm curious, what does the update mask look like that successfully updates the field? does it just set serviceAccount? I'm wondering whether I could make a quick fix to our templates that would get that parameter into the updatemask.

[MartinNowak]

I'm curious, what does the update mask look like that successfully updates the field? does it just set serviceAccount?

Yes, it's just serviceAccountName and inserting that here works.
It's a bit atypical for the gcloud API to include such parameters in the query string (without returning it anywhere), hence there is no precedence.

I'm wondering whether I could make a quick fix to our templates that would get that parameter into the updatemask.

A hack around the issue would be to move all of the update_mask logic to a piece of custom code, but that seemed out of scope and less maintainable in the long-run.
How about we do a followup PR if you find a good extension point?

[danawillow]

Follow-up PR sounds good. Can you add an example (which will become a test) that sets the new field?

[MartinNowak]

I added a test-case that sets service_account_name @danawillow, though the query parameter is input only so has to be ignored for the ImportStateVerify.

[modular-magician]

Hi! I'm the modular magician. Your PR generated some diffs in downstreams - here they are.

Diff report:

Terraform GA: Diff ( 4 files changed, 80 insertions(+), 5 deletions(-))
Terraform Beta: Diff ( 4 files changed, 80 insertions(+), 5 deletions(-))

[danawillow]

Thanks @MartinNowak!