Fix for lost clipboard contents (#5424)

[gavynriebau]

Fixes the issue described in #5424

The code has been changed so that for unix type platforms a call is made to libc::setsid using the unix specific CommandExt pre_exec.

The setsid call happens just after fork has been called and before execve is called. This means it runs in the context of the child process.

The call is necessary to ensure that spawned child processes related to the clipboard (e.g. xclip) have a distinct process session ID and process group ID.

Without this change when the parent process exits, the child (i.e. xclip), can be erroneously killed leading to copy/paste breaking in some specific circumstances such as those detailed in #5424

[archseer]

setsid should be called on all unix systems:

Suggested change

	if cfg!(not(any(windows, target_os = "wasm32", target_os = "macos"))) {
	use std::os::unix::process::CommandExt;
	unsafe {
	command_mut = command_mut.pre_exec(|| match libc::setsid() {
	-1 => Err(std::io::Error::last_os_error()),
	_ => Ok(()),
	});
	}
	}
	#[cfg(unix)]
	unsafe {
	use std::os::unix::process::CommandExt;
	command_mut = command_mut.pre_exec(|| {
	if libc::setsid() == -1 {
	return Err(io::Error::last_os_error());
	}
	});
	}

For windows we might also want to pass .creation_flags(CREATE_NEW_PROCESS_GROUP)

[gavynriebau]

I've made the following changes:

• Call setsid for all unix systems
• Call .creation_flags(CREATE_NEW_PROCESS_GROUP) for windows

After making the changes I've realised the change to set CREATE_NEW_PROCESS_GROUP will never be executed as it is inside a mod provider that uses the config #[cfg(not(target_os = "windows"))].

Seeking your opinion but I am thinking of reverting back by one commit so that the PR will contain no code related to setting CREATE_NEW_PROCESS_GROUP for windows but keeps the change you suggested of calling setsid for all unix systems?
Removed changes related to setting process group for windows as they weren't relevant

Separate to this PR but I'm also considering doing a follow-up PR to cleanup the code a little, let me know if you think this would be valuable?
With the amount of conditional compilation attributes I found it slightly hard to follow what was going on andwas thinking of splitting the code out into separate files for each environment, e.g. a provider file for windows, macos, osc52, wasm, unix etc..

[gavynriebau]

I think these changes are ready for another review now.

I'm not able to change how pre_exec is called to exactly as you suggested because it needs to return a Result<()> type.

[archseer]

Should this be listed under [target.'cfg(unix)'.dependencies? It probably doesn't make a difference

[gavynriebau]

Thanks, yes, you're right, it's a dependency that's, for now, only used on unix platforms. I've addressed this now.