Implement secrets cp command

[tegefaulkes]

Specification

The secrets cp command is very similar to the secrets mv command. It will copy the provided paths to the provided destination.

1. copy a file to a destination directory
2. Multiple source paths can be specified. The last argument is the destination.
3. Globing and wildcards are supported.
4. Globing is supported for the destination. but only the last of the list is the destination. I say we don't support it.

There are two main differences between the mv command.

1. The source files are left unchanged the copied. The Inode of the source and destination are different.
2. The destination files are always created fresh and overwrite the destination.

So there are no subtle behaviours with the moving the file vs copying them between filesystems.

Additional context

Related #32

Tasks

1. Implement a secrets cp command
2. Supports copying a file from source path to destination.
3. And take a variable number of source paths with the last path being the destination.
4. Supports globing and wild cards.
5. Supports copying directories with contents.

[linear]

ENG-362 Implement `secrets cp` command

[CMCDragonkai]

I want to point out that cp here is going to be one of the most complex commands and most used commands probably.

You have consider these scenarios:

• cp from 1 vault to another vault (thankfully sharing all the same EFS root now)
• cp from vault to real fs
• cp from real fs to vault
• cp from real fs to real fs?? If you imagine secrets cp ./a ./b could this just run as usual?

Then imagine that all works also recursively.

[tegefaulkes]

Yeah, it's a complex and I've considered most of that already.

I think the most complex part of this is the recursive walking and globing of the file paths. I've already completed a utility for this in MatrixAI/Polykey#767 which works on real fs along with our fs. It supports the whole glob standard using minimatch which is what NPM uses to check glob patterns.

Along with that there's sending the file tree across the network so we can write it between the real FS locally and the node's efs. I'm half way through this now with MatrixAI/Polykey#774.

Besides that I still need to work out how I want to structure the RPC commands. If we say, want a specilized RPC for CP, or more generalised RPC for plumbing. I need to do some prototyping to get an idea of the constraints. The plumbing style might require the ability to lock and hold transactions between RPC calls.

[aryanjassal]

I remember having a discussion about the case where we perform cp (or mv) from real fs to real fs. The conclusion was to make this operation unsupported. The reasoning was that there are a lot of caveats and specifics when copying to another place in the real fs. This might not be an issue or might be expected when dealing with efs to real fs and flip, but this might not hold when performing between two real fs paths, and might subvert expectations. As such, this will generate an error stating cp cannot work on two real fs paths.