Feature/websocket lifecycle callbacks

[francisjervis]

trafficstars

This PR adds callbacks on_socket_connect and on_socket_disconnect to enable (among other things) state restoration in the absence of authentication/built-in data persistence and handling of connectivity issues with the client.

The current on_chat_restore handler depends on the Chainlit data layer and and on_chat_start/on_chat_end are ambiguous wrt their handling of 1: WS status changes 2: user intent - for instance, on_chat_end is called if the server times out the connection (#2198).

on_chat_resume does not appear to be called (even if the data layer is enabled) after a WS drop/reconnect event cycle. on_chat_start is not called if the WS connection is dropped and re-established, only on the first connection for a session. Note that the current documentation for on_chat_start has "to react to the user websocket connection event" which is ambiguous/misleading.

In at least some contexts this leads to a silent failure state (on both ends) where user inputs are not processed, there is no "disconnected" message shown to the user, and there is no backend signal. This is particularly problematic when the WS connection drops after an AskUserMessage was sent.

While there is certainly some overlap with the existing chat lifecycle callbacks, adding unambiguous/unopinionated network state change handling both avoids breaking changes (ie renaming/refactoring the chat start/end callbacks) and adds the ability to use "hand-rolled" state persistence approaches which do not depend on the Chainlit auth/data layer features.