Lack of optimization regarding copy and delete jobs

## The Accepted Solution's Efficiency: Upgrade or Side-grade?

This comment explains my understanding of how "async pfcon" implemented in https://github.com/FNNDSC/ChRIS_ultron_backEnd/pull/696 and https://github.com/FNNDSC/pfcon/pull/157 evolve the overhead and performance of _ChRIS_.

### Background

- (Subjectively,) _ChRIS_ has had a reputation of having inefficient overhead because of polling, duplicated files in storage, and excessive copying of data.
- Originally, _ChRIS_ would transmit all of a plugin instance's input data to pfcon in a **zip** file.
- pfcon "**innetwork**" mode was implemented in https://github.com/FNNDSC/pfcon/pull/137
- It's now possible for _CUBE_ and _pfcon_ to share a "storebase" volume.
- This meant that there was no need for data transmission whatsoever.
- Startup overhead was reduced to its theoredical minimum.
- _CUBE_ "**chrislinks**" feature was implemented in https://github.com/FNNDSC/ChRIS_ultron_backEnd/pull/568 and https://github.com/FNNDSC/pfcon/pull/142
- It's now possible for _CUBE_ to run a set of hard-coded operations (so-called "_ts_-type" plugins) _without_ making redundant copies of files.
- Storage consumption was greatly optimized.
- Caused backwards-incompatible API change.
- Storage is no longer "transparent" meaning if you were to look at the storage volume's filesystem, files might not physically exist where they logically do. Hence, any component which interfaces with _CUBE_'s storage must be aware of and implement logic to resolve so-called "link"-type files and folders. This additional burden is based on conventions about
- Implementation of _pfcon_ must now be _CUBE_-aware. Previously, _pfcon_'s behavior and API were agnostic to its role in the _ChRIS_ backend architecture. Now, _pfcon_ is more strongly coupled to _CUBE_ via conventions of how _CUBE_ storage works.

Currently, the so-called ["async pfcon" (v6.0.0)](https://github.com/FNNDSC/pfcon/releases/tag/v6.0.0) has been merged. The motivation for "async pfcon" was to be able to handle situations with large file count per _ChRIS_ plugin. The implementation is as follows: (1) _each_ time a plugin instance runs, a _copy_ job is created which ensures that input files are present in the input directory. (2) _each_ time a plugin instance terminates, a _delete_ job is created which cleans up the copies of the input directory.

### Copy Inefficiency

Suppose you have a feed where `A` has three children, `B`, `C`, and `D`.

```
A
/ | \
B C D
```

In this situation, the current implementation will make 3 copies of `A`'s outputdir, and delete it 3 times. This is inefficient, especially considering that the whole point of "async pfcon" feature was to deal with large directories.

### Suggested Fix: Smart copying and GC

- When `C` or `D` is created, _CUBE_ should notice that there already exists a copy and can reuse `B`'s inputdir.
- Deletion should not be _eager_. Deletion should happen e.g. 24 hours after all children of `A` have terminated. This strategy is analogous to "garbage collection" (GC).