Add websocket option update on component variable change

[klemmpnx]

• if certain ControllerComponentVariables are changed, updates the websocket options (without a reconnect)
• removes the reset of connection_attempts on option settings since
  • unclear, why this is part of setting the connection options (which does not have further side effects)
  • so far, in libocpp set_connections_options is only called in the context of a websocket init (which implies connection_attempts=0)

[Dominik-K]

I suggest to better make it explicit in the options itself.

One way could be to split up the WebsocketConnectionOptions into two parts: WebsocketConnectionOptionsNeedsReconnect and WebsocketConnectionOptionsNoReconnect. That way it's clearly indicated directly at the source of the fields what it means when changing them.

Perhaps you have a better idea, though?

[klemmpnx]

I suggest to better make it explicit in the options itself.

One way could be to split up the WebsocketConnectionOptions into two parts: WebsocketConnectionOptionsNeedsReconnect and WebsocketConnectionOptionsNoReconnect. That way it's clearly indicated directly at the source of the fields what it means when changing them.

Perhaps you have a better idea, though?

Hmm yes that is tricky.

I do not quite understand the intention how the Websocket class is to be used. The Websocket class does offer the set_connections_options method, but does not really take care of it. I would actually expect that if I change options that require a re-connect, then the Websocket would take care of this. But this would be purely internal, so the outside classes would not need to care - so also (at least from the outside) not split would be required.
However, we already do care outside (in case the basic auth settings change). And in fact the Websocket does nothing when options are changed....

So if we want to refactor this, I would rather make the websocket API safer instead of putting more knowledge/responsibility outside (and then also kick out this distinction between with/without reconnect). But I am not 100% aware of all implications here and also not sure, this should go into this PR then?

[Pietfried]

I suggest to better make it explicit in the options itself.
One way could be to split up the WebsocketConnectionOptions into two parts: WebsocketConnectionOptionsNeedsReconnect and WebsocketConnectionOptionsNoReconnect. That way it's clearly indicated directly at the source of the fields what it means when changing them.
Perhaps you have a better idea, though?

Hmm yes that is tricky.

I do not quite understand the intention how the Websocket class is to be used. The Websocket class does offer the set_connections_options method, but does not really take care of it. I would actually expect that if I change options that require a re-connect, then the Websocket would take care of this. But this would be purely internal, so the outside classes would not need to care - so also (at least from the outside) not split would be required. However, we already do care outside (in case the basic auth settings change). And in fact the Websocket does nothing when options are changed....

So if we want to refactor this, I would rather make the websocket API safer instead of putting more knowledge/responsibility outside (and then also kick out this distinction between with/without reconnect). But I am not 100% aware of all implications here and also not sure, this should go into this PR then?

There are quite some implications that need to be considered when changing the internal websocket handling and unfortunately the requirements of v16 and v201 differ a little bit concerning the change of ws options / reconnect / fallback handling. I agree that a general refactor makes sense, but I see this as part of another PR.