[filebeat][streaming] - Added more retry codes to websocket retry logic

[ShourieG]

Type of change

• Bug

Proposed commit message

Some valid websocket retry codes were missing from the initial implementation, which could lead to retries not occurring in some scenarios, hence added some more codes to retry on. There is a table below that shows what codes are currently retryable and why.

Table Of Reasons

+---------------------------------------+---------------------------------------------------------+---------+
| Close Code                            | Description                                             | Retry?  |
+---------------------------------------+---------------------------------------------------------+---------+
| 1000 - CloseNormalClosure             | Connection closed normally.(can be a false positive)    | Yes     |
| 1001 - CloseGoingAway                 | Endpoint is going away (e.g., server shutdown).         | Yes     |
| 1002 - CloseProtocolError             | Protocol error (e.g., malformed frames).                | No      |
| 1003 - CloseUnsupportedData           | Unsupported data type received.                         | No      |
| 1005 - CloseNoStatusReceived          | No status code provided (abnormal closure).             | Yes     |
| 1006 - CloseAbnormalClosure           | Abnormal connection closure (unexpected).               | Yes     |
| 1007 - CloseInvalidFramePayloadData   | Invalid payload data (e.g., bad UTF-8).                 | No      |
| 1008 - ClosePolicyViolation           | Policy violation (e.g., authentication issues).         | No      |
| 1009 - CloseMessageTooBig             | Received message exceeds allowed size.                  | Yes     |
| 1010 - CloseMandatoryExtension        | Required extensions not supported.                      | No      |
| 1011 - CloseInternalServerErr         | Server encountered an unexpected error.                 | Yes     |
| 1012 - CloseServiceRestart            | Server is restarting.                                   | Yes     |
| 1013 - CloseTryAgainLater             | Server is overloaded; try again later.                  | Yes     |
| 1015 - CloseTLSHandshake              | TLS handshake failure (e.g., certificate issues).       | Yes     |
+---------------------------------------+---------------------------------------------------------+---------+

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Disruptive User Impact

Author's Checklist

• [ ]

How to test this PR locally

Related issues

• Relates [proofpoint_on_demand]: Datastreams do not recover after websocket error integrations#11816

Use cases

Screenshots

Logs

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @ShourieG? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-8./d is the label to automatically backport to the 8./d branch. /d is the digit

[mergify]

backport-8.x has been added to help with the transition to the new branch 8.x.
If you don't need it please use backport-skip label and remove the backport-8.x label.

[elasticmachine]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[botelastic]

This pull request doesn't have a Team:<team> label.

[kcreddy]

LGTM 👍🏼 Just need a clarification.

In CloseMessageTooBig case, is the message responsible for the error discarded or does the retry makes attempt to read same message with increased size limit?

[ShourieG]

LGTM 👍🏼 Just need a clarification.

In CloseMessageTooBig case, is the message responsible for the error discarded or does the retry makes attempt to read same message with increased size limit?

@kcreddy, the gorilla websocket does not impose any limits on the frame size, these limits are only imposed by the websocket protocol so this can't be increased. Since the messages are streamed they are sent in individual frames. There is no such hard limit to the message size.
So for this error it's generally a protocol violation from the server or something weird that's going on and could be resolved via retries