feat: tf api metrics

[acpana]

Change description

Adds support for tf level metrics too!

$ curl http://localhost:8888/prom-metrics | grep "gcp_api_requests_total"

# HELP configconnector_gcp_api_requests_total Total number of GCP API requests
# TYPE configconnector_gcp_api_requests_total counter
...
configconnector_gcp_api_requests_total{controller_name="tagstagkey-controller",method="GET",status_code="2xx"} 4
configconnector_gcp_api_requests_total{controller_name="tagstagkey-controller",method="POST",status_code="2xx"} 3

Special notes for your reviewer:

Does this PR add something which needs to be 'release noted'?

• Reviewer reviewed release note.

Additional documentation e.g., references, usage docs, etc.:

Intended Milestone

Please indicate the intended milestone.

• Reviewer tagged PR with the actual milestone.

Tests you have done

• Run make ready-pr to ensure this PR is ready for review.
• Perform necessary E2E testing for changed resources.

[acpana]

in my experience, we needed to clone this Config as the Context that it uses for HTTP requests is the one that we first configure the provider with AND NOT the ctx that we have in hand here.

[yuwenma]

/lgtm
/assign @maqiuyujoyce

[cheftako]

Seems strange you are passing 1 context directly to sync and a different context to sync through the meta object.

[acpana]

Yes that's what I wanted to highlight here:

#4880 (comment)

Note "we" were always doing this before in that the TF Apply command takes in the ctx for some operations but for actual HTTP calls and transport calls it uses the Context in the meta

[cheftako]

Still don't like this. To quote from https://go.dev/blog/context-and-structs "Contexts should not be stored inside a struct type, but instead passed to each function that needs it."

To quote from https://pkg.go.dev/context "Do not store Contexts inside a struct type; instead, pass a Context explicitly to each function that needs it. This is discussed further in https://go.dev/blog/context-and-structs. The Context should be the first parameter, typically named ctx:"

[cheftako]

I realize this is not an anti-pattern your putting in, but it is very much an anti-pattern.

[acpana]

/hold want to merge #4879 first

[acpana]

/hold cancel

[cheftako]

/hold want to merge #4879 first

4879 is merged

[justinsb]

Does this really need to be in the third_party directory? Could we maybe move it into the controller, and have a function like CloneAndChangeContext, and in the comment for that we say what it is doing, how this is sort of a hack, but it's a reasonable thing to do given what we have to work with.

[cheftako]

/lgtm
/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cheftako

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [cheftako]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment