Introduce secure copy, recursive copy, and move functionality

[dmlloyd]

Fixes #484.

This is a draft to allow review of the API and basic implementation as I write tests. Based on #482.

• copy (SDS input)
  • Tests
• copy (Path input only)
  • Tests
• copyRecursively (SDS input)
  • Tests
• copyRecursively (Path input only)
  • Tests
• move (SDS input)
  • Tests
• move (Path input only)
  • Tests
• copyEvenIfInsecure (Path input only)
  • Tests
• copyRecursivelyEvenIfInsecure (Path input only)
  • Tests
• moveEvenIfInsecure (Path input only)
  • Tests

[dmlloyd]

One issue I struggled a little bit with is in regards to one detail of copying.

Most copy utilities will look at your destination path, and if it's a directory, will copy the source file/directory into the target directory under the same name as the original. If it's a file that exists, it will attempt to replace that file with the copy (or fail if you don't have replacement enabled).

The JDK however behaves differently with its (strictly non-recursive) Files.copy() method. If the target is a non-empty directory, the copy fails (even if you specify REPLACE_EXISTING). If it is a file or an empty directory, and REPLACE_EXISTING is set, then the original file is deleted before copying.

One other little detail is that on UNIX-like systems, if your destination path ends with / then it's always taken to mean a directory to copy the original to, and will fail if the path is actually a file. With java.nio.file.Path, any trailing / are removed during parsing, so that behavior is not possible to implement.

The proposed API follows the JDK behavior, not because I think it's better, but because with the restriction on Path it would be basically impossible to be able to specify that the destination is a directory into which the file should be copied/moved. Also, I think that deviating a lot from the JDK idioms would be a source of confusion and bugs.