Verify v2 client requesting directory hosted with intermediate path elements sets subdirectory ID correctly

[nothingmuch]

If the directory is deployed behind e.g. a reverse proxy and requests are rewritten exposing the public URI with a path, the current behavior of the pj_url derivation is to replace the path in its entirety.

In some places in the code .join is used, appending the subdirectory ID but the sender uses set_path as well.

[DanGould]

Fixed by #448

[DanGould]

Because of our tangled arch this was difficult to verify even though it was probably resolved. Leaving this open until we have a proper test that a directory hosted with additional path elements beyond the host is verified as functional in the v2 flow.

[arminsabouri]

cc @nothingmuch please provide closing rationale

[nothingmuch]

This issue is no longer relevant because since RFC 9540 support the directory's gateway must be /.well-known/ohttp-gateway and it doesn't make much sense to allow the directory target resource to have additional path components.