Add path validation to signers & verifiers

[alexheretic]

Since path should always start with / we can validate that this is the case and return a helpful error before an incorrect signature or incorrect verify usage ends in an opaque error.

E.g. trying to use the whole url .path("https://example.com/foo"). We could produce something like an error invalid path "https://example.com/foo" must start with '/'.

We can use the full url scenario as a new test for signing & verifying in all langs.

Checklist:

• C# (C#: Add path arg validation to Signer & Verifier #73)
• Go (Golang: Add path arg validation to Signer & Verifier #76)
• Java (Golang: Add path arg validation to Signer & Verifier #76)
• Java7 (Java7 #98)
• NodeJS (nodejs: Add path validation #70)
• PHP
• Python (python: adds path validation + jku to signer + path trailing slash #81)
• Rust (rust: Add path validation assertions #77)

[LukeMathWalker]

Perhaps invalid path, you passed an absolute URL. The path must be relative, starting with '/'?
It might even be possible to suggest the correct one by playing around with HTTP URL parsing (e.g. you probably wanted to pass '/foo'?).

[alexheretic]

Perhaps invalid path, you passed an absolute URL. The path must be relative, starting with '/'? It might even be possible to suggest the correct one by playing around with HTTP URL parsing (e.g. you probably wanted to pass '/foo'?).

That would be very nice, but the biggest win is just having any error saying "path" instead of just generating an invalid, or failing verify a, signature which indicates very little. So the simplest impl is just ensuring the path starts with /.

[alexheretic]

Also related to the proposed reason deduction, but this issue is much easier to achieve https://truelayer.slack.com/archives/C01UYLYQ2HE/p1655124955742179

^^ that would actually suggest the correct path in the signing case. I should move that proposal to an issue here...