First activity will have a bogus replyToId if it was from the bot

Version

master (as of pre-R12)

Describe the bug

Although this is a SDK bug, I am filing it here because we have // TODO code to remove after that bug is fixed.

First activity will have a bogus replyToId if it was from the bot.

If this bug is not fixed, it might cause accessibility issues on our side.

• When the bot is sending the very first activity in the conversation, that activity always have a bogus replyToId
  • The replyToId has a value, but the value is random string, and it refer to an activity that never exists in the world
• SDK team should remove the replyToId as the value is not a valid
  • This is the root cause of #3431, the PR I did is to workaround their bug, and introduced a new but less severe issue
  • If we don't remove replyToId in SDK and keep the workaround in #3431, it will cause issue in this scenario:
    • If both user and bot send activities to each other immediately after connect, the order of the message could be different: what the user see, and what they hear through screen reader, will be different
    • IMO, this issue is less severe than a 5s delay, so I prefer we implement this workaround in the mean time

Steps to reproduce

1. Edit /__tests__/html/accessibility.delayActivity.withReplyToId.html
2. Remove the // TODO line related to this bug
3. Run the test

Expected behavior

It should succeed, reasons:

• The user sent the activity "Hello, World!"
• ABS did not send us the activity ID yet for the "Hello, World!" activity
• The bot (thru ABS) already sent us the reply, "You said, ...", with a replyToId pointing to "Hello, World!"
• Since the activity that replyToId is pointing to, is not known yet, the bot reply "You said, ..." should not appear on the transcript

To fix #3431, we have to relax the delay for the very first bot message, since it may have a bogus ID, or it may have a valid ID, we can't tell whether the replyToId is valid or not. We assume the first one is bogus, so we don't add 5 seconds delay.

But that PR inevitably introduced another accessibility issue, which is less severe, IMO.

The // TODO line is to send a bot activity first, so the bot reply, "You said, ..." activity, is no longer the first bot activity, and it should subject to delay.

Additional context

Developers who are not familiar with how ABS works and how it order messages, should read this sequence diagram first.

https://github.com/microsoft/BotFramework-WebChat/blob/master/docs/media/direct-line-sequence-diagram.png

For accessibility, the order of the narration is based on time when we add the element to the tree. And not based on the actual position of the element in the tree.

[Bug]