Fix flaky test of visualization tool

[Hailong-am]

Description

This PR is add waiting for model to be undeployed to fix flaky test introduced by #2363,

https://github.com/opensearch-project/ml-commons/actions/runs/8933312245/job/24539185907?pr=2402

Issues Resolved

[List any issues this PR will resolve]

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[ylwu-amzn]

The worst case this line will run MAX_TASK_RESULT_QUERY_TIME_IN_SECOND times, it will be 300 ? For every retry, it will sleep one second, so it will wait for 300 seconds, that's a long time. Do we really need so long time ? We should fail quickly within a reasonable time

[Hailong-am]

yeah, reduce to total 30s that should be enough for model to be undeployed.

[rbhavna]

Thanks @Hailong-am for fixing the flaky tests. @ylwu-amzn This issue is not just for flaky tests. The undeploy response is giving UNDEPLOYED immediately but we still have to rely on get model to see if the model is indeed undeployed. Could be confusing to users. We should either give a task_id or say something like UNDEPLOY INITIATED in the undeploy response if the model is not completely undeployed

[dhrubo-os]

Thanks @Hailong-am for fixing the flaky tests. @ylwu-amzn This issue is not just for flaky tests. The undeploy response is giving UNDEPLOYED immediately but we still have to rely on get model to see if the model is indeed undeployed. Could be confusing to users. We should either give a task_id or say something like UNDEPLOY INITIATED in the undeploy response if the model is not completely undeployed

Seems like @ylwu-amzn created an issue for this.

[dhrubo-os]

Do we need to backport this to 2.14 branch? I don't see any backport label to this PR.

[ylwu-amzn]

Do we need to backport this to 2.14 branch? I don't see any backport label to this PR.

I think this test case seems not flaky in the Release CI workflow. We don't see IT failure report yet. To not block the whole release. I think it's fine to not backport to 2.14

[opensearch-trigger-bot]

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.x 2.x
# Navigate to the new working tree
cd .worktrees/backport-2.x
# Create a new branch
git switch --create backport/backport-2416-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 aa09014abdd0a890c9ea3a55bf472ecc7eb7e480
# Push it to GitHub
git push --set-upstream origin backport/backport-2416-to-2.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-2416-to-2.x.