Component catalog connectors: consider supporting the 'file' scheme

[ptitzler]

Is your feature request related to a problem? Please describe.
Several catalog connectors utilize the requests library to download specifications from remote sources. In environments where network connectivity is rather limited the VPE becomes almost unusable because download might take a long time or fail frequently.

Describe the solution you'd like
Augment the existing connectors to also accept file - scheme based URLs. This can be accomplished by implementing a transport adapter.

Additional context

file-scheme based URLs

• provide better performance because all resources are stored locally (+)
• are less portable than HTTP/S-based URLs because they don't support shared resources (-)
• provide functionality that is similar to the functionality that the filesystem catalog connector implements but have the advantage that one could (relatively) seamlessly switch between 'local' and 'remote' component location by updating the component catalog connector configuration

[kevin-bates]

I like this idea. So would the idea be that the transport adapter would represent a well-defined prefix with, what follows that, the "path" to the catalog? So if we had a URI of http://github.com/foo/bar/baz.py, one could use file://my_root/my_dir/foo/bar/baz.py where http://github.com gets replaced with file://my_root/my_dir when configured to use the "local" mode? I think we'd have to configure the prefixes for each "protocol". E.g.,

{
    "remote_prefix": "http://github.com",
    "local_prefix": "file://my_root/my_dir",
    "access_mode": "local"
}

and the schema for "access_mode" is an enum of ["local", "remote"]?

If so, are transport adapters necessary? Seems like requests should just recognize the scheme by default.

[kevin-bates]

Just saw your PR and it appears we just use whatever URL is configured - great. So requests doesn't naturally support file: schemes?

[ptitzler]

Unfortunately not. If you enter such a URL retrieval will fail without the PR. I only implemented support for those connectors that made sense. For example, handling file:///path/to/mlx-server for the MLX connector would be meaningless.

I saw significant performance improvements for the package-based connectors because the network overhead (several seconds) was eliminated.