chore(metrics): Align error_type enum values

[lucperkins]

When working on Cue configuration for internal metrics in PR #4820, I noticed some discrepancies in the possible values for error_type (a tag for the processing_errors_total metric). This PR provides a convenient enum mechanism for keeping these values aligned.

[binarylogic]

This seems really close to #978. I'm wondering if we'd want to make these classifications part of the error event directly?

[lucperkins]

@binarylogic That's certainly a possibility as part of a more comprehensive refactor of how we do this. I would say, though, that this PR wouldn't fundamentally impede such an effort; in fact, such an undertaking could use the same ErrorTypes enum in their implementation. So I think this work improves the current situation at little cost to future changes, but I'm happy to defer to others if this isn't much of a win. In that case, I could repurpose this PR as a simple standardization of the existing error_type values as raw strs.

[binarylogic]

Sounds good.

[lucperkins]

@bruceg @JeanMertz I'm happy to defer to both of you on this. To summarize, the two questions on the table:

1. Whether it's preferred to use enums for things like this (personally, I would argue in favor of that, as it provides a centralized "store" for possible values, which can prevent discrepancies). If there's consensus that the enum-driven approach is better in general, I'd be happy to go through and change this in other areas (the op_kind field in the Kubernetes metrics is another example).
2. Whether the error_type should be included in the respective error structs.

But I have no dog in this fight, so I'm also happy to restrict this PR to just renaming the various error_type fields to remove inconsistencies.

[bruceg]

1. Whether it's preferred to use enums for things like this (personally, I would argue in favor of that, as it provides a centralized "store" for possible values, which can prevent discrepancies).

I agree here. Anywhere we want to restrict the cardinality of something, we should be trying to use an enum. It would be nice to take it a step further yet, by only accepting those enums. This could be introducing a step where the enum is either enforced by type (ie a function for emitting the error counter) or a macro that accepts an identifier instead of an expression (so strings aren't usable).

2. Whether the `error_type` should be included in the respective error structs.

This doesn't seem to make as much sense. Each error struct will result in a single ErrorType being emitted, so including that value in the struct seems redundant.

[JeanMertz]

Two minor nits, but nothing blocking, and I agree with @bruceg's comments, but would defer enum enforcement to a follow-up PR, since this seems (almost) good to go as-is.

[bruceg]

I'm not sure this type of structure has any real benefits over a set of constants, at least without further work on emitting these errors. It doesn't enforce (in the compiler) that we only use these values, and requires extra code at each invocation (which admittedly will be completely inlined in release builds). It does add a namespace (ErrorTypes) but that can also be provided with a module.

[lucperkins]

@bruceg @JeanMertz Oops, I made the changes requested by Jean without reading Bruce's comment. I have no strong feelings re: enum vs. const. Happy to defer on that if either of you feels particularly strongly. If the enum approach is okay, I'll fix the current errors; otherwise, I'll revamp.

[lucperkins]

There doesn't seem to be consensus around the right way to do this, and I suspect there will at some point be a broader effort to standardize, so I'm going to close this. Happy to revisit and help out at any point.