File system metadata not sufficiently captured per requirements

[jordanpadams]

Describe the bug
Per requirement nasa-pds-engineering-node/pds-registry-app#67, the following information was not captured as expected. More details given as to what is expected for these fields and the rationale for capturing it.

• base file path for product(s) – this should be the actual path(s) to the product(s) on the file system and/or a separate field for the URL so someone could easily download them

• checksum (_file_md5 also refers to the label) – even though this metadata is in the label, we shouldn’t trust that. Also, that metadata is optional in the label, and we will want this for every product in the archive so we can eventually use the registry for integrity checking and our software to deliver products to the NSSDCA

• file size (_file_size also refers to the label) – Richard, is this required in the products themselves? If is, I would still like us to duplicate this information to some other field (e.g. _product_size) so we have all the “metrics” fields named similarly so they can be easily found in the output.

• file timestamp (don't see this at all) – I was thinking this would be the timestamp of the file on the filesystem. Some folks use this for integrity checking to see if/when the file was touched.

• MIME type (also don't see) – I would like us to also have a _product_mime_type (or some similar name) for what it is according to the filesystem, not necessarily the label.

issue identified by @rchenatjpl

Applicable requirements:
🦄 nasa-pds-engineering-node/pds-registry-app#67

[tloubrieu-jpl]

@tdddblog envision difficulties in getting the mime type for pds binary data files. apache-tika is a candidate for getting the mime type.

[tloubrieu-jpl]

Impacts on harvest, registry-mgr and registry-app