pageserver: avoid logging the "ERROR" part of DbErrors that are successes

[jcsp]

Problem

The pageserver<->safekeeper protocol uses error messages to indicate end of stream. pageserver already logs these at INFO level, but the inner error message includes the word "ERROR", which interferes with log searching.

Example:

  walreceiver connection handling ended: db error: ERROR: ending streaming to Some("pageserver") at 0/4031CA8

The inner DbError has a severity of ERROR so DbError's Display
implementation includes that ERROR, even though we are actually
logging the error at INFO level.

Summary of changes

Introduce an explicit WalReceiverError type, and in its From<>
for postgres errors, apply the logic from ExpectedError, for
expected errors, and a new condition for successes.

The new output looks like:

    walreceiver connection handling ended: Successful completion: ending streaming to Some("pageserver") at 0/154E9C0, receiver is caughtup and there is no computes

Checklist before requesting a review

• I have performed a self-review of my code.
• If it is a core feature, I have added thorough tests.
• Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
• If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

• Do not forget to reformat commit message to not include the above checklist

[github-actions]

1264 tests run: 1212 passed, 0 failed, 52 skipped (full report)

---

[jcsp]

(force push because it's entirely different approach)

The more I picked at trying to make a more explicit check for the condition instead of playing with messages, the more it seemed to make sense to use some structured error enums here instead, and do traditional error matching instead of the is_expected route.

This is a more invasive change, but the overall LOC change is only about +10 compared with the old way, and it makes us ready to use the SuccessfulCompletion variant for logic as/when we need to.

[koivunej]

Overall this is looking great, we are on the path to recognize the "ending streaming" succesful completions and can propagate that upwards once all or some subset of safekeepers have closed wal streams for this reason. Unsure though if we know how many safekeepers there should be; probably only probabilisticly.