API for working around path problems linking descriptors downloaded from servers

[jhump]

A previously merged fix (#169) addressed the file path matching problem for loading linked-in local registered files (#147). It turns out, the same sort of thing is needed for remote files, when using server reflection.

The way the grpcreflect package interacts with the server reflection interface is to first use one of the various methods to get an "entry point" into the descriptors. But these returns one file descriptor at a time. So to link a file descriptor, we have to ask for its imports, and the way that is done is by name. It turns out that this can encounter the exact same kinds of problems: the name (and path) of a given file, for querying for the descriptor by name, may differ from how it is referenced by import statements in other files. So, when resolving a file, we ask for the observed import path, for which the server may reply with a "not found" error if the name and path don't match.

So we basically need an ImportResolver for the grpcreflect package -- when linking a file, it will try to map import paths to "canonical registered paths" when asking the remote server for that file.

[danielvladco]

Hello, thanks for the great library!

I just came across this issue. are there any plans on fixing this? I see it is open for quite some time.

Maybe you can help work around this issue until it is not fixed?