Better handling for long-running dsl watcher methods

[shawkins]

Is your task related to a problem? Please describe

Informable.inform or any Watchers use the okhttp websocket thread for handling event processing. If the user has a long running method (greater than several seconds), which they are advised not to, that will trigger an exception due to not handling the pong. However the exception handling currently just triggers the watch to be restarted, which can cause concurrent calls on the Watcher which is not expected.

I don't believe this should not be an issue with the java client.

Describe the solution you'd like

At the very least this should be more strongly documented and the usage of async event handling encouraged.

Describe alternatives you've considered

No response

Additional context

No response

[shawkins]

Part of what contributes to this issue is that the integration tests rely on ClientResourceProvider to create the injected KubernetesClient. It passes the existing uber/shaded v4 Config to the instance be constructed. Since that has a different default for websocket ping interval the integration tests will use 1 second rather than 30 seconds - which makes it very likely for debugging to trigger this issue.

@rohanKanojia @manusa does this warrant another issue?