zstash is impractical for exascale simulations

`zstash create` is way too slow to be practical for km-scale global simulations. The issue seems to be collecting all the files into a tar file before moving it to HPSS. I think zstash also uses hsi under the hood and OLCF says hsi is much slower than htar, which is much slower than globus. I ended up having to use a 1 node batch job to try to do this. It ran for the max allowable 2 days then timed out, so I restarted it with `zstash update` and had to resubmit it every few days for weeks. I think one of my cases might have finished, but I never was able to verify if all the data got uploaded.

`zstash check` is also impractical for these big simulations - it takes weeks to upload the data and even longer to download it again. Perhaps there could be a "quickcheck" option that just ensures that all the files in the original directory are found in the zstash index and that the total file size is consistent with the sum of the individual files you tarred? I'm also still a bit confused why we can't checksum the data on HPSS without moving it back to scratch.

All of this isn't to say that zstash isn't great for what it was made for and it's fine if we never end up using it for exascale simulations. I'm just providing my experience as the first exascale zstash user.

Start by tracing the zstash create, update, and check command entry points to understand where archive creation, HPSS transfer, and verification occur. The issue does not name files or tests; done would require an agreed scalable approach and a practical way to verify large simulations without the current multi-day transfer cycle.

Written by the indexing model from the issue text.