Set custom timeout for x11 server connection.

[fufesou]

1. Add an error type X11ServerConnTimeout.
2. Add apis of set and get conn timeout for x11.

SHORT_TIMEOUT_DUR may be not enough sometimes.

Retry and longer timeout may be required.

[complexspaces]

Hey there, thanks for the PR.

I was a little afraid of this when I accepted the PR adding the timeout handling for X11 originally. The original PR actually had the inverse goal of this one: don't wait too long when nothing is going to respond. You seem to want the behavior where it is willing to give a server more time and those goals conflict since each direction wastes more hang time of its opposite.

I'm not personally a fan of having more mutable global state in this case as well. I'd like to think about this one a bit and see if anything else comes to mind.

If you don't mind, I have some questions that might help generalize this:

1. What conditions are you using X11 under that take too long? A network?
2. How long are you seeing your use case take?
3. Is your application specific where you could implement a retry loop? We do this on Windows internally (because every other Win32 application in existence does) but its hard to justify on Linux given the desktop environment diversity.

[fufesou]

I use arboard in desktop software that develop with flutter. https://github.com/rustdesk/rustdesk/

I ran the program in a virtual machine and noticed that on rare occasions it would take more than milliseconds. It probably takes up to 20ms to complete.

I've tried a retry loop.

https://github.com/rustdesk/rustdesk/blob/1794b6518243e081c02977c66439005cb399e14d/src/common.rs#L1426

But I'm not sure a retry can cover all cases.

[complexspaces]

I've decide to revert the X11 timeout functionality in #147, for the reasons I stated earlier and in that linked PR. I just don't think its sustainable to carry the timeout functionality when different parties want opposite behavior.

My recommended path forward for you would be to wrap your call(s) to Clipboard::new() in the same std::thread::spawn and channel here. That way you will also be able to control the timeout as you like.