Swartzn/fix/remote node connection handler

[swartzn]

This patch does solidifies the worker connect/connection handler behavior. The connection handler should only stop trying to reconnect to the worker when remote itself is shutting down. So I propose two alternatives with a preference for the second,

1. Redefine retry in the grpcClientHandler interface's connect function to isErrTransient. This keeps the beesync connection code the same but realigns the interface with the expected behavior. This allows us to cleanly adjust remote's worker connection handler so that there are two error types: 1) transient errors (rpc/network) and 2) non-transient errors (version/config). Keeping these error types separate allows for a fixed retry delay for the non-transient errors.

   • To see this implementation, just look at the first commit.

2. Remove retry/isErrTransient altogether from the grpcClientHandler interface's connect function. This unifies the errors so that they are all retried under the same exponential backoff mechanism.

   • To see this implementation, look at all the changes together.

What does this PR do / why do we need it?

Required for all PRs.

• Fixes the remote worker node shutdown.
• Aligns grpcClientHandler connect semantics with the expected behavior.

Related Issue(s)

Required when applicable.

Where should the reviewer(s) start reviewing this?

Only required for larger PRs when this may not be immediately obvious.

Are there any specific topics we should discuss before merging?

Not required.

What are the next steps after this PR?

Not required.

Checklist before merging:

Required for all PRs.

When creating a PR these are items to keep in mind that cannot be checked by GitHub actions:

• Documentation:
  • Does developer documentation (code comments, readme, etc.) need to be added or updated?
  • Does the user documentation need to be expanded or updated for this change?
• Testing:
  • Does this functionality require changing or adding new unit tests?
  • Does this functionality require changing or adding new integration tests?
• Git Hygiene:
  • Do commits adhere to Conventional Commits?
  • Is the commit history squashed down reasonably?

For more details refer to the Go coding standards and the pull request process.