Handle error classification coming from RUCSS without link to the retry capacity

[MathieuLamiot]

Is your feature request related to a problem? Please describe. It is difficult today to analyze error results from the RUCSS service as we don't have a normalized error classification.

Describe the solution you'd like Some kind of error code or error typology should be returned by the RUCSS service to categorize errors, received and stored by the WP-Rocket plugin. It is currently done based on the 'code' field which only contains error code 500 (no retry) and error code 408 (retry). This field is therefore mixing up two issues : error classification and retry capabilities which, for evolution and compatibility should be separated (see additional context). Typically, a dedicated field in the response like 'error_type' could allow to classify issues. The code (408/500) could just be maintained for compatibility, driven by the could_retry field discussed here. Here are the error categories to be reported so far:

• Protocol error (Target.setAutoAttach): Session closed
• Navigation timeout
• Browser couldn't open a new page

Describe alternatives you've considered Otherwise, we could depreciate the 'code' field and replace its usage. This would break compatibility with plugins that don't support the 'could_retry' field.

Additional context Discussions leading to this issue are available here.

Acceptance criteria

• When receiving a categorized error from the RUCSS server, the plugin should store the corresponding error category, as listed above.
• When receiving an unknown error / not categorized error from the RUCSS server, the plugin should store the error message without specific category.
• Errors previously triggering a retry should still trigger a retry, through the 'could_retry' field (and 'code' as well, if we want to keep compatibility)