fix(error_reporting): respect quota_project configuration

[torreypayne]

This PR fixes an issue where the Google::Cloud::ErrorReporting client was ignoring the quota_project configuration parameter, causing API calls to default billing to the project associated with the credentials. This resulted in PermissionDeniedError (Error Reporting API not enabled) for users attempting to report errors to a target project that was different from their credentials project (e.g. issue #25862).

closes: #25862

Changes

• Updated Google::Cloud::ErrorReporting.new to resolve quota_project from the library configuration and pass it down to the internal Service layer.
• Updated Google::Cloud::ErrorReporting::Service to accept quota_project and apply it to the underlying gRPC client configuration.
• Documented quota_project usage in README.md and AUTHENTICATION.md.
• Added unit tests to verify configuration propagation.

Expectation Setting on Project vs Quota Project

In Google Cloud APIs, the Target Project (where resources are stored/written) and the Quota Project (which project is billed for the API call) are intentionally separate concepts:

• By default, the library bills the project associated with your credentials.
• If you need to report errors to a project that differs from your credentials project, you must explicitly configure quota_project via library configuration or the GOOGLE_CLOUD_QUOTA_PROJECT environment variable.

How to configure:

Google::Cloud::ErrorReporting.configure do |config|
  config.project_id    = "target-project-id"   # Where errors are reported
  config.quota_project = "billing-project-id"  # Project billed for the quota (optional)
end
# Client will now respect the configured quota project for billing
client = Google::Cloud::ErrorReporting.new

=====

Manual testing logs:

irb(main):011> Google::Cloud::ErrorReporting.configure { |cfg| cfg.quota_project = 'global-billing-project' }
Key :pretty_print does not exist. Returning nil. at /usr/local/google/home/torreypayne/.gem/ruby/4.0.0/gems/pp-0.6.3/lib/pp.rb:212:in 'block (2 levels) in PP::PPMethods#pp'
=>
irb(main):012> er = Google::Cloud::ErrorReporting.new(project_id: "your-target-project")
=>
#<Google::Cloud::ErrorReporting::Project:0x00007f970b587d80
...
irb(main):013> # Verify it picked up the global configuration
irb(main):014> puts "Service Quota Project: #{er.service.quota_project}"
irb(main):015> puts "GRPC Quota Project: #{er.service.error_reporting.configure.quota_project}"
Service Quota Project: global-billing-project
GRPC Quota Project: global-billing-project
=> nil
irb(main):016> er = Google::Cloud::ErrorReporting.new(project_id: "your-target-project", quota_project: "your-billing-project")
=>
#<Google::Cloud::ErrorReporting::Project:0x00007f97083d6778
...
irb(main):017> # Verify it picked up the global configuration
irb(main):018> puts "Service Quota Project: #{er.service.quota_project}"
irb(main):019> puts "GRPC Quota Project: #{er.service.error_reporting.configure.quota_project}"
Service Quota Project: your-billing-project
GRPC Quota Project: your-billing-project
=> nil
irb(main):020> er = Google::Cloud::ErrorReporting.new(project_id: "your-target-project")
=>
#<Google::Cloud::ErrorReporting::Project:0x00007f9708442018
...
irb(main):021> # Verify it picked up the global configuration
irb(main):022> puts "Service Quota Project: #{er.service.quota_project}"
irb(main):023> puts "GRPC Quota Project: #{er.service.error_reporting.configure.quota_project}"
Service Quota Project: global-billing-project
GRPC Quota Project: global-billing-project

[aandreassa]

Looks great! A couple nits

[aandreassa]

Maybe move this line down and just use left alignment? It looks a bit off here since others are part of the parameter list.

[aandreassa]

Slightly more idiomatic to split the steps:

@quota_project = quota_project
@quota_project ||= credentials.quota_project_id if credentials.respond_to? :quota_project_id

[aandreassa]

Could these be something else, such as String for project_name? You may be able to grab the specific type for event as well.

[aandreassa]

My hesitation here is this config not being isolated. I assume if the step above fails, then the config could leak into other tests. Should it have an after block instead like others?