feat(converse): converse api

[samuelmasse]

Adds a collector to the message api to replicate behavior similar to the converse api

Closes DEV-1909
Closes DEV-1612

Requires to be on this branch when testing: botpress/botpress#5568

[linear]

DEV-1909 Port converse to messaging

DEV-1612 Add a "collect messages" option to the send message route to get behavior similar to the converse api

• watch out when multiple calls to converse api (list of collectors ?)

[allardy]

What do you think of using messaging as a simple proxy for converse ?

Right now, when you call converse, we start a timeout of 5 sec before considering the request as completed and sending back a response to the user. This delay is paused as long as an action is running, and the timeout is cleared as soon as the conversation is completed, so there is no "random" delay (like your 3 secs).

Basically, the route could be User -> Messaging -> Call /converse on runtime, wait for response, then -> User ?

[samuelmasse]

@allardy I don't think messaging should depend on the runtime. What we'll do to make this a bit better is remove the await for the typing indicators delay, so that the runtime sends all of its messages one after the other. To avoid all the messages being sent at the same time, we'll put the messages in a queue in the channel code, so they are sent sequentially and they wait for each typing indicator.

We'll still need a magic number for how much we wait, but it'll be much smaller and it won't depend on the amount of time a typing indicator lasts on a certain message.

[laurentlp]

I will pre-approve this, but we'll merge it once you have made the fix for the typing indicators.

[allardy]

@samuelmasse The runtime will not be exposed to the outside world, so communications must go through messaging. Is this a good replacement for the converse api, and can we use it to benchmark messaging with botpress efficiently ?

[samuelmasse]

Merging this right now. I'll make the final improvements in another PR