[c-lightning] Support Plugin for optimally splitting of payment amounts and invoices for AMP payments

[ZmnSCPxj]

Good morning Rene!

Thank you very much for this.

As is my wont, I will now completely derail the conversation, sorry!

As to approach --- personally I think it is better, to be able to split up the `pay` command into smaller subcommands.
I could point to how `fundchannel` has been split up into `fundchannel_start`, `txprepare`, `fundchannel_complete`, `txsend`, for example.

It is always possible that users might desire to change or tweak *one* part of the `pay` command, without changing the rest of the `pay` sub-algorithms.
In such a case, it would be better to have various sub-algorithms of `pay` be accessible as commands over the RPC.
That way, the `pay` plugin can be replaced, but the sub-algorithms that it uses can simply be reused if those parts of the overall `pay` algorithm are considered to still be useful for the new `pay` overall algorithm.

As an example, perhaps there can be a `pay_retryloop` command which accepts a `getroutemethod` that indicates the JSON-RPC method to use for getting a route, `getrouteparams` for extra parameters to pass into the given `getroutemethod` (in addition to "standard" parameters like `id`, `fromid`, `msatoshi`, `cltv`, `fuzzpercent`, and `exclude`), and congruent `sendpaymethod` and `sendpayparams` parameters.
Then experimental `pay` plugins can replace the pathfinding algorithm (and maybe the `sendpay` algorithm... or not?) without having to reimplement the failure-retry code, which has gotten complicated because of the merge of `final_expiry_too_soon` into `incorrect_or_unknown_payment_details`).
Then the `paystatus` and

Now of course those algorithms can be put in some library somewhere, but an advantage of our RPC is that it doubles as well as an adaptor for calls across different programming languages.
Typically a library will be implemented in *some* language, and then we would have to design an interface in a different language that wants to call into that.
The use of the command RPC means that the effort to build an interface is only needed once (you only need to implement the JSON-RPC in your preferred language) and you can now call into each and every plugin command, regardless of language barriers.

Granted this approach has problems:

* The RPC is not an efficient way to perform calls, as it requires serialization of data into a rather "heavy" text format.
  Thus, some algorithms cannot be split down further (e.g. pathfinding algorithms) without tremendous slowdowns.
* It exposes lots of tiny methods to end users, as traps lying in wait for them to accidentally misuse.
  * However, as I understand it, in practice end users use GUIs to interact with C-Lightning, and the discoverability of such tiny methods can instead help upgrade a technically-curious end-user to a plugin developer.

Regards,
ZmnSCPxj