feat: Add postgres logs error collector to database_observability.postgres component

[gaantunes]

PR Description

Implementing a Postgres logs parser focused on error collection, with the following capabilities:

• Extracts insights from log messages, like affected tables, columns, blocker and blocked pids, among others
• Generates metrics from the error lines, categorizing errors by sqlstate_code, user, queryid, auth failures and more
• Accepts the JSON format only, given its the recommended format for parsing Postgres logs

Which issue(s) this PR fixes

Notes to the Reviewer

PR Checklist

• Documentation added
• Tests updated

[cristiangreco]

@gaantunes I've done a first pass, my feeling is that we're doing more than needed at this stage, I'll explain:

• I'd focus on producing one single metric, postgres_errors_total, but change the labels from "severity", "database", "instance" to "database", "instance", "queryid". This seems to be the core of what we'd need to show an error rate (global and per-query).
• ignore anything else for now, e.g. no need to parse anything other than query error messages, no need for other metrics IMO. We also don't need to write back to EntryHandler a custom log line, we just need the metric really.

So my ask is to basically to trim it down dramatically and keep it very, very simple as first pass. We can still re-introduce later anything else that seems useful.

[gaantunes]

Hi @cristiangreco.
Customers have showed interest in knowing what is the exact error in previous feedbacks. If we are already going to parse the logs to have metrics, why not provide this information already?

[gaantunes]

As discussed in our 1:1 this will be split into different PRs to approach the problem iteratively.

[github-actions]

💻 Deploy preview available (feat: Add postgres logs error collector to database_observability.postgres component):

• https://deploy-preview-alloy-5080-zb444pucvq-vp.a.run.app/docs/alloy/latest/

[clayton-cornell]

Suggested change

	The `error_logs` collector is always active and processes PostgreSQL error logs in JSON format (requires `log_destination = 'jsonlog'` in PostgreSQL configuration).
	The `error_logs` collector is always active and processes PostgreSQL error logs in JSON format.
	This requires `log_destination = 'jsonlog'` in your PostgreSQL configuration.

[clayton-cornell]

Suggested change

	Unlike other collectors, `error_logs` does not need to be enabled via `enable_collectors` - it automatically processes any PostgreSQL JSON logs that are forwarded to the component.
	Unlike other collectors, `error_logs` does not need to be enabled via `enable_collectors`.
	It automatically processes any PostgreSQL JSON logs that are forwarded to the component.

[clayton-cornell]

Suggested change

	- Data values in `detail` and `context` fields (such as constraint violations, key values, and row data)
	- Data values in `detail` and `context` fields such as constraint violations, key values, and row data

[clayton-cornell]

Suggested change

	- Parenthesized values in error messages (e.g., `Key (id)=(123)` becomes `Key (id)=(?)`)
	- Parenthesized values in error messages, for example, `Key (id)=(123)` becomes `Key (id)=(?)`

[clayton-cornell]

Suggested change

	Setting `disable_query_redaction` to `true` will expose SQL query parameters, constraint values, and other potentially sensitive information in error logs.
	If you set `disable_query_redaction` to `true`, it will expose SQL query parameters, constraint values, and other potentially sensitive information in error logs.