make client connected timeout configurable

[WolfgangFahl]

see also #1046

Changing the timeout logic here slightly in client.py would IMHO be useful.

1. add default_time_out to constructor
2. set timeout to None as default
3. if timeout is None use default_time_out of instance

async def connected(self, timeout: float = 3.0, check_interval: float = 0.1) -> None:
        """Block execution until the client is connected."""
        self.is_waiting_for_connection = True
        deadline = time.time() + timeout
        while not self.has_socket_connection:
            if time.time() > deadline:
                raise TimeoutError(f'No connection after {timeout} seconds')
            await asyncio.sleep(check_interval)
        self.is_waiting_for_connection = False

[falkoschindler]

Why would a default timeout in the constructor (i.e. initializer) help? The client isn't instantiated by user code, so an initializer parameter is rather useless. Maybe you don't mean to add a parameter, but just a member variable instead.

What would be an application for the default timeout? connected can only be awaited once, so you don't avoid any code duplication.

[WolfgangFahl]

@falkoschindler thank you for looking into this. When refactoring my scan2wiki application from Flask to nicegui/FastAPI/Starlette the OCR and Upload functions needed some love since these are long running request that might well take over a minute to run.

see #2018 for how a change in implementation finally got this issue addressed

Still some part of the code seems to overrun the default 3.0 second timeout so i ended up:

@ui.page('/upload/{path:path}')
        async def upload(client:Client,path:str=None):
            await client.connected(timeout=10.0)
            return await self.upload(path)

Which currently is a per page implementation. I still have more old Flask and even Java RESTFul API's to migrate some have timeouts set to 2 hours. I assume this won't be a problem for non-UI calls via FastAPI and for UI calls it might be necessary to always go the background-thread route.

I still believe being able to make the client connected timeout configurable would be good for debugging issues with the timeout e.g. finding out what happens during the time period the timeout kicks in and then fix these problem.