retPath as a retrieval path to override relPath

extracted from an email thread...

From @josusky:
Another interesting idea that Peter mentioned is a logical difference between retrieval URL and the relative path or file name. I can confirm that some systems require use of quite complex URLs to provide the "right" data. In the current concept the client uses the relative path for both - construction of the URL needed the retrieve the data as well as a local "path" or file name to store it. Of course, in many cases such data will be consumed without actually creating a local file or without worrying about its readability but if we adopt the use of two separate fields "retPath" and "relPath" with one of them being optional then we will be able to elegantly handle broader range of data sources.

**My proposal is the keep "relPath" as a kind of a canonical product instance identifier, while the (optional) "retPath" (if specified) would be used instead of it to construct the URL that the data provider needs to unambiguously identify the data instance in its data store (whatever it is).**

No files, tests, or implementation entry points are named. Start by locating where relPath is used to construct retrieval URLs and where the data provider identifies a data instance; done means an optional retPath can override URL construction while relPath remains the canonical product identifier.

Written by the indexing model from the issue text.