[Access] Add client id for subscriptions

[Guitarheroua]

This should be discussed with the FCL team due to the comment: #6630 (comment)

Update after meeting:

1. For all actions ("subscribe," "unsubscribe," "listOfSubscriptions"), the client will generate and pass a unique correlation UUID as an argument.
2. The backend will receive and store the correlation UUID until the action is completed.
3. After an action is completed (successfully or unsuccessfully), the response sent back to the client should include the unique correlation UUID provided by the client in request to the WebSocket controller.

[jribbink]

Thanks for making this issue @Guitarheroua.

@illia-malachyn 's comment from the other thread:

The ID in SubscribeMessageResponse is generated on the server side to ensure that each subscription has a unique identifier. This approach prevents clients from spoofing or forging IDs, enhancing security by reducing the potential for unauthorized access or manipulation. By associating the Topic with this unique ID in the response, clients can reliably match a SubscribeMessageRequest to its corresponding SubscribeMessageResponse.

Topic is indeed redundant and might not be included in a response. We're still discussing it

My concern is that associating subscribe requests to responses on the basis of Topic alone can be ambiguous if a client sends multiple consequetive SubscribeMessageRequest messages to the server with the same Topic.

Presumably this is a potential scenario when a user wants to subscribe to the same topic multiple times, but with different parameters.

It seems to me that either:

1. Some sort of identifier must be sent from the client to associate SubscribeMessageRequest and SubscribeMessageResponse messages.

   Sorry for initially stating that this should correspond to the same ID as SubscribeMessageResponse was maybe a mistake on my part - this can be a totally different identifier.

2. OR The server must guarantee in-order delivery of SubscribeMessageResponse messages. In this case, I can just add pending subscriptions to a queue on the client-side & associate them with incoming responses in-order.

Maybe 2. is already a guarantee, and in this case this would not be an issue to worry about. But I just wanted to bring it up in the case that it isn't.

[Guitarheroua]

Thanks for making this issue @Guitarheroua.

@illia-malachyn 's comment from the other thread:

The ID in SubscribeMessageResponse is generated on the server side to ensure that each subscription has a unique identifier. This approach prevents clients from spoofing or forging IDs, enhancing security by reducing the potential for unauthorized access or manipulation. By associating the Topic with this unique ID in the response, clients can reliably match a SubscribeMessageRequest to its corresponding SubscribeMessageResponse.

Topic is indeed redundant and might not be included in a response. We're still discussing it

My concern is that associating subscribe requests to responses on the basis of Topic alone can be ambiguous if a client sends multiple consequetive SubscribeMessageRequest messages to the server with the same Topic.

Presumably this is a potential scenario when a user wants to subscribe to the same topic multiple times, but with different parameters.

It seems to me that either:

1. Some sort of identifier must be sent from the client to associate `SubscribeMessageRequest` and `SubscribeMessageResponse` messages.
   Sorry for initially stating that this should correspond to the same ID as `SubscribeMessageResponse` was maybe a mistake on my part - this can be a totally different identifier.

2. OR The server must guarantee in-order delivery of `SubscribeMessageResponse` messages.  In this case, I can just add pending subscriptions to a queue on the client-side & associate them with incoming responses in-order.

Maybe 2. is already a guarantee, and in this case this would not be an issue to worry about. But I just wanted to bring it up in the case that it isn't.

Hey, @jribbink! I'm sorry for not getting back to you sooner. I think a second option would require more synchronization work on the WebSocket side and increase the complexity of maintaining order while keeping and sending requests/responses. The first option is the easiest to implement, and, as I see it, this is referred to as the "Correlation Identifier Pattern". Here’s how this could be implemented:

1. Use a client-generated correlationId in each SubscribeMessageRequest and echo it in the SubscribeMessageResponse to ensure the response corresponds to the correct request.
2. Include a WebSocket-generated subscriptionId in the response for lifecycle tracking. This ID will identify the subscription and will also be used to unsubscribe.

[bluesign]

Another option is to embed request into response ( SubscribeMessageResponse will contain SubscribeMessageRequest )

I feel it is a bit cleaner and easier on the client side handling. ( considering subscription response will be the first message of the stream, but I think it has to be in any case )