Should return zero records in table if the service API is not enabled

[LalitLab]

Is your feature request related to a problem? Please describe.

In GCP plugin, if we get errors like this: connection 'gcp_thor': rpc error: code = Unknown desc = googleapi: Error 403: Cloud Functions API has not been used in project 123456789321 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/cloudfunctions.googleapis.com/overview?project=123456789321 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry., accessNotConfigured

Describe the solution you'd like
It is reasonable to return 0 rows as service is not enabled on the project. Hence no resource of that type will be available.

[cbruno10]

Re-opening as we've had a recent request for the opposite behaviour in #430

The changes as a result of the issue was actually reverted in https://github.com/turbot/steampipe-plugin-gcp/pull/432/files due to the issue mentioned above. It's understandable that users may want to also see the errors, but other times( like when running compliance checks for a large number of projects where some services are never used), that 0 rows is a better result.

Right now, if you want to ignore service disabled errors, you need to ignore all 403 errors, e.g., ignore_error_codes = ["403"].

One change we could make is to add an additional config arg that allows ignoring of service disabled errors specifically, e.g.,

ignore_service_disabled_errors = true

It would default to true but could be set to false so queries will error when encountering this error.

An alternative is to add a special error code that ignore_error_codes, like ServiceDisabled, that we'd handle specially (even if GCP never throws this error), e.g.,

ignore_error_codes = ["ServiceDisabled"]

[cbruno10]

Discussing with @johnsmyth , we could also add a new config arg that takes regular expressions in and matches against error messages to allow users to ignore errors beyond just the HTTP codes.

[rajlearner17]

Referring the fresh issue raised based on Slack communication.

[cbruno10]

I believe we have a better long term solution in #476. I'm closing this issue as this issue's intent doesn't match up with the PR exactly, and there's already an ongoing discussion on design in the PR.