We previously simplified the client-side flow and reduced the amount of superfluous tracking in #88. However, this also removed an easy way for the client to clearly associate events with the previously made requests.
In this PR we go a step further and:
a) Return the request_id from request_opening_params, re-introducing the means to associate requests/events, without the need for additional tracking of user_channel_ids or similar.
b) Return the request_id from select_opening_params and use it to track the requests everywhere, allowing us to drop user_channel_id entirely. This doesn't only mean we don't have to keep track of it separately, but also that we don't have to expose an API that might be misused, requiring us to check and document the uniqueness properties of the identifiers.
c) Since we now ended up with essentially a single client side state, we drop the InboundChannelState tracking entirely.
d) We commit to not support 'LSP-trusts-client' mode any time soon and just remove it from the API.
We previously simplified the client-side flow and reduced the amount of superfluous tracking in #88. However, this also removed an easy way for the client to clearly associate events with the previously made requests.
In this PR we go a step further and:
a) Return the
request_idfromrequest_opening_params, re-introducing the means to associate requests/events, without the need for additional tracking ofuser_channel_ids or similar. b) Return therequest_idfromselect_opening_paramsand use it to track the requests everywhere, allowing us to dropuser_channel_identirely. This doesn't only mean we don't have to keep track of it separately, but also that we don't have to expose an API that might be misused, requiring us to check and document the uniqueness properties of the identifiers. c) Since we now ended up with essentially a single client side state, we drop theInboundChannelStatetracking entirely. d) We commit to not support 'LSP-trusts-client' mode any time soon and just remove it from the API.