[v2] Fix flaky prompt-toolkit tests

[hssyoo]

The PromptToolkitAppRunner test utility only waits 2 seconds for the app to finish rendering. This causes flaky test failures because prompt-toolkit is tested using EC2 service model, which is ~3MB and can take a few seconds to load on hosts with low resources. This PR changes the test service model to CloudWatch, which is ~230KB.

Also bumps the event timeout to 5 seconds to allow more time for the app to render for input buffer tests. Unlike other flaky tests, there's not a slimmer command/model to switch to.

[nateprewitt]

Assuming we get a clean run without having to retry 🤞

[nateprewitt]

The one failure seems to match a lot of the cases I've seen:

functional/autoprompt/test_prompttoolkit.py::TestPromptToolkitPrompterBuffer::test_input_buffer_initialization[args3-s3 ls ] - AssertionError: assert 's3 ls' == 's3 ls '

For whatever reason we're missing trailing spaces on some of the tests periodically. I haven't looked at this at all but 1.) is the trailing space relevant and 2.) if not can we just normalize the strings by trimming before comparison?

[hssyoo]

The one failure seems to match a lot of the cases I've seen:

functional/autoprompt/test_prompttoolkit.py::TestPromptToolkitPrompterBuffer::test_input_buffer_initialization[args3-s3 ls ] - AssertionError: assert 's3 ls' == 's3 ls '

For whatever reason we're missing trailing spaces on some of the tests periodically. I haven't looked at this at all but 1.) is the trailing space relevant and 2.) if not can we just normalize the strings by trimming before comparison?

It's relevant because when autoprompt is enabled and a command is entered with no ambiguity, then there will be a trailing space. For example, aws s3 ls is unambiguous since there aren't any other s3 commands that fuzzy-match with ls. But aws ec2 is ambiguous because it could be ec2, ec2-instance-connect, etc.

I was able to reproduce this locally by setting the event timeout to a very low value. So what I assume is happening is that the test is actually failing to render the app by timing out, so the input aws s3 ls stays as-is, instead of being transformed to aws s3 ls by the prompt-toolkit app. I think bumping the timeout from 2 to 3 seconds should make this much less common.

[hssyoo]

Played around with this a bit on my fork. I timed the test durations and saw a couple instances of prompt-toolkit tests taking ~3.5 seconds. Setting the timeout to 5 seconds for now and the plan is to monitor future CI runs to see if we need to bump it higher or look into improving performance of the autoprompt feature. Not too worried about the bump causing longer test times since this is only observed in GitHub CI and it's faster than manually retrying failed builds.