Change all references in user-facing error messages to point to discussions instead of issues

[chaas]

In some cases, I first added a new discussion item to track the feature request and then updated the error message to reference the discussion item.
In other cases, I removed the issue reference if it wasn't useful anymore or something that users are likely to ask for.

Motivation

• This PR refactors existing code. In service of the plans to make Github issues private, and use Github discussions for public tracking instead.

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

[benesch]

Thank you!

[jkosh44]

LGTM

[antiguru]

We need to be careful with this change as it can prevent data from being compacted in persist. We should determine if we have any of these errors durably recorded in persist before merging the change.

[jkosh44]

These are not used in the catalog persist shard. Would they be used anywhere else?

[chaas]

We do write the error message text to mz_internal.mz_statement_execution_history (the activity log) in some cases. Would this change make it so the index on the activity log wouldn't compact properly?

[antiguru]

I think we can write the error proto itself to any persist shard, but I'm not exactly sure about this variant. Someone who knows more would need to check.

The issue is that once we fix the error, we'd generate a retraction, but that retraction would not match any durable error, so both the insert and retraction would stay around forever. The same problem happens for the in-memory representation I think and can cause problems at runtime.

[benesch]

In this case, changing the name of the field won't change its on-disk encoding, so we can do that to get around the problem. @chaas can you remove the reserved 2 and bumping the field number, and just do a rename of the existing field with ID 2?

[antiguru]

I think I successfully confused myself! For the in-memory representation, it shouldn't cause problems because the persist sink self-corrects the contents of a materialized view. Only the persist compaction might leave things around that are semantically equivalent but have a different bit pattern. So, retracting my request changes!