The network interface or other infrastructure going down does not necessarily mean the “connection is lost” - TCP may keep trying to retransmit for a long time before killing the connection (depends what happened - an error on the local interface will probably cause an immediate error, but a router going down somewhere along the path may not).
It’s not up to the kernel, it is determined by the TCP protocol and the “userspace app” could very well wait a long time before receiving an error on the socket.
To answer each sub-question specifically:
- I've seen suggestions of up to 9 minutes before timeout (I think some of these timeouts might be configurable, where the protocol allows it and things like TCP keepalives can be configured to cause timeouts earlier);
- the kernel doesn't hide things, or try to "reconnect", it simply follows the TCP protocol, continually re-trying sending of un-acknowledged segments ... the "userspace app" is simply suspended inside the system call (e.g. write(), sendto(), etc) i.e. the "userspace app" is running in kernel mode and it's context is switched out and won't be switched back until some event makes the process "runnable" again;
- while suspended, the "userspace app" may be "uninterruptible" which means you can't kill it, even if you use SIGKILL (i.e. kill -9) as root - "graceful exit" may not be an option (although, I don't think this can happen with send on a socket, it has to be something that is considered to be short term and high priority - e.g write to a file on NFS with hard mount and intr flag not set can do it) ... but even if it is an option, the "app" must be written to catch errors and exit gracefully itself - if the kernel makes the "app" exit, it won't be graceful :-) (e.g. it won't run exit handlers or free up resources allocated outside the "app", etc)