Fix significant security holes with "use chroot = no" in an rsync daemon:
1. The file paths being sent and received were not "sanitized" to
ensure that there weren't any ".." components that would escape the
top level directory. This can't happen with the standard rsync
client, but it could be exploited on both read and write if someone
modified an rsync client. This fix sanitizes all incoming and
outgoing paths when "use chroot = no".
2. If a module is also "read only = no", clients could have created
symbolic links with ".." components that would allow writing
outside of the module. This could happen with the standard rsync
client. This fix sanitizes all incoming symbolic link targets
when "use chroot = no".
Previously, only top-level paths (anything passed in command line arguments)
were sanitized. Sorry, I didn't think about the individual file paths
before now.