Code indicates chaining rules should work with specialtyBot routing, but there are two bugs preventing function

[gaijin1973]

Describe the bug
Evaluation of chaining rules should allow automatic flow to a subsequent question when specialtyBot processing is complete. However, I believe there are two problems:

1. If no responsebot_hook setting exists, the chaining will be evaluated immediately, both concatenating the follow-on question's text with the text of the question intended to initiate bot routing, and preventing the routing from happening by failing to incorporate (in the merge_next method) the specialtyBot configs from hit1 routing question into hit2 found by the chaining rule. It doesn't seem intuitive that setting a responsebot_hook would be necessary in this case, and I was actually expecting a validation error when I added that setting without a corresponding namespace.
2. Once I could get into the bot routing flow, although I could properly return to QnA bot with the QNABOT_END_ROUTING session attribute, there was no way to get into the code block for chaining rule evaluation, since "specialtyBotProgress" is not a key set anywhere in the codebase other than to 'undefined'. (https://github.com/aws-solutions/qnabot-on-aws/blob/main/lambda/fulfillment/lib/middleware/3_query.js#L62-L63)

To Reproduce

1. Set up a question with both Bot Routing configs and Chaining Rule configs.
2. Set up a question with both Bot Routing configs and Chaining Rule configs, but also add a value for Elicit Response responsbot_hook.

Expected behavior
A clear and concise description of what you expected to happen.

1. The answer from the specialty bot question should display, subsequent routing should be through the specialty bot, and upon exit from the specialty bot, the chaining rule should be evaluated for document chaining.
2. It's possible this should be an invalid configuration, since no elicit response namespace is designated. However, if not, then the scenario should behave as described in scenario 1 expected behavior.

Actual results

1. When the routing question is encountered, the chaining rule is evaluated, the designated question is found via ES search, that question's answer is concatenated to the routing question's answer, and the following questions remain in the QnA Bot context rather than the routed bot's context.
2. When the routing question is encountered, the chaining rule is not evaluated, the routing question's answer is displayed, and the following questions are properly routed to the routed bot's context. However, on exiting the specialtyBot via the designated methods, the chaining rule cannot be evaluated because the conditions to reach that code can never be satisfied.

Please complete the following information about the solution:

• Version: 5.2.0
• Region: us-east-1
• Was the solution modified from the version published on this repository? No
• If the answer to the previous question was yes, are the changes available on GitHub? N/A
• Have you checked your service quotas for the services this solution uses? No, not sure how that would be relevant here.
• Were there any errors in the CloudWatch Logs? No

Screenshots
If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context
Add any other context about the problem here.

[bobpskier]

@gaijin1973 I've been looking to see if the issues with botrouting can be resolved. There are multiple issues at present. I plan on submitting a pull request in the next couple of days that addresses the issues I've been encountering. These are mainly defects routing to Lex V2 bots (dialog state), defects routing to other Lex V2 based QnABots, merging messages for text and markdown especially from other QnABots, and finally conditional chaining on completion / end of routing. I'm also planning on adding the ability to send an initial utterance to the target bot and merge back select session attributes returned from the target bot to a specified namespace.

[marcburnie]

@gaijin1973 - we're providing bot routing enhancements and fixes provided by @bobpskier PR: #575. These changes will be made publicly available during the next minor release (in a few months), which should resolve this issue. I will close this ticket once the changes have been merged.

[marcburnie]

This issue has been resolved in v5.5.0.