[MERGE][#299254] Fix RemoteTransport's translation of errors involving paths; it wasn't passing orig_path to _translate_error.

[Andrew Bennetts]

Vincent Ladeuil wrote:
[...]
> That wasn't and still isn't a major concern. Yet,
> bzrlib.remote._translate_error isn't the clearer piece of code
> I've seen. One drawback, for example, is that such a design make
> it impossible for an outsider to find which smart verbs can raise
> which exception (or even a single given exception). As long as we
> don't need to find these relations too often, there is no need to
> change it though.
> 
> One big pro is that unknown errors are handled, which may be more
> complicated in an alternate design.

Well, basically at the moment any method might raise any error.  It's hard
to pin down exactly which errors are reasonable for a particular verb, which
is pretty similar to the bzrlib API.  For example with sufficiently screwed
up filesystem permissions I could imagine that PackRepository.autopack might
fail with PermissionDenied.

And if a server does return an error that seems inappropriate or surprising
for a particular RPC, I think translating to the corresponding bzrlib error
is no worse (and possibly better) than raising a generic protocol error.

For outsiders (i.e. third party implementations of the API), the rule is
currently simple: be prepared to handle any defined error regardless of the
RPC used.

It might not be completely elegant, but I don't see much practical benefit
in changing it.

-Andrew.