shadowsocks-rust: [Bug] `sslocal` cannot daemonize when a plugin is specified via config file

Bug description

sslocal cannot daemonize using the -d or --daemonize flag when the config file specifies a plugin.

I am not entirely sure that this is 100% the real issue here, but I have tested on two different OSes (RHEL8 & Arch) and observed the same behavior, so let’s just say I am reasonably confident.

To replicate

Here I will use simple-tls as an example, but the choice of plugin seems irrelevant. On a Linux x64 machine:

1. Get required binaries - sslocal v1.11.2 (latest stable at the time of writing), simple-tls or any other plugin
2. Get the config files: configs.zip
3. Verify that when -d is not used, sslocal runs correctly

# Both should run fine
sslocal -v -c ss.json
sslocal -v -c ss-plugin.json # you might have to edit plugin path

1. Verify that when -d is used without a plugin, sslocal daemonizes correctly

sslocal -v -c ss.json -d --daemonize-pid ss.pid
ps aux | grep sslocal # expect sslocal is running

1. Verify that when -d is used with a plugin, sslocal no longer daemonizes

sslocal -v -c ss-plugin.json -d --daemonize-pid ss-plugin.pid
ps aux | grep sslocal # expect no sslocal process

Environment & versions

uname -msr
Linux 4.18.0-305.19.1.el8_4.x86_64 x86_64

sslocal --version
shadowsocks 1.11.2

whoami
root