Clnrest: dynamic paths

[daywalker90]

based on #7507, #7508 and #7509

Adds the capability for clnrest to handle dynamic paths registered via a plugin's manifest. Supports the http methods GET and POST and arbitrary content-type's for responses. The most specific path is chosen if there are multiple matches.

lightningd is responsible for making sure no ambigous paths like /path/to/<me> and /path/to/<you> are registered.

[niftynei]

adding v1 to all custom endpoints might prove problematic if someone's attempting to match an external spec.

In the case of cashu, which is currently v1, this is fine but in the case that cashu moves to v2 this will cause problems.

[daywalker90]

That's a very good point. The versions are not correlated and could change independently. Do we need to add a version field to the clnrest manifest data?

[niftynei]

it's also possible to have specs that don't include the version part of the path!

I think there's two options here:

• add an optional "version" field which defaults to the current CLN rest one. it can be set to 'null' which removes it entirely.
• don't add the version to the endpoint but instead have rpcs add it to their path explicitly.

[gudnuf]

also would be problematic for cashu if clnrest moves to v2, but cashu does not

add an optional "version" field which defaults to the current CLN rest one. it can be set to 'null' which removes it entirely.

This would help maintain a static endpoint if clnrest bumps its version