feat: implement sender and receiver policies based on v1 result codes

[b-garbacz]

PR Description

This PR improves consistency in v1/network error handling and connection policies, while increasing test reliability.

What changed

• Aligned v1 result codes and overall error handling.
• Replaced ResultCodePolicy with connectionPolicies and migrated related tests.
• Introduced custom errors for ConnectionManager.
• Updated MessageOrchestrator:
  • retry behavior,
  • validator selection,
• Refactored message broadcast failure messages for clarity.
• Enhanced account endpoint tests to cover internal error scenarios.
• Updated sendSingleMessage documentation for clarity and detail.

Outcome

More consistent error/result behavior, cleaner networking code, and more stable test coverage.

[leonardotc]

So, if this line disappeared. Cant you just remove the flag from the Error? In general, that is also not great in terms of design. Exceptions (or things that throw) are done in a pub-sub design. That means that the emitter should work as broadcast and the observer (subscriber) should know how to handle those accordingly. If you pass a behavior flag, you are making it so the emitter know the behavior of the subscriber beforehand.

[jusufsuljic]

We could maybe check the result codes here and decide whether to close the connection.

[b-garbacz]

Okay, so the plan is to create a new module that defines the behavior based on V1ProtocolError, in a similar way to ResultCodePolicy.js It would be even better to rename that file to ResultCodesPolicies.js.

In that module, we would have:

• a sender connection handling policy (Success, Rotate, NoRotate)
• a validator connection handling policy (the ResultCodes that should cause us to close the validator connection).

It will have one big benefit - centralizing all policies into a single file.

@leonardotc @jusufsuljic @leonardostsouza I’m going to merge the current PR as is, and then create a followup issue to refactor it in this direction.