Enable tests that were muted during migration

[oakrizan]

Proposed commit message

Enabled muted && skipped tests

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Related issues

• Relates: https://github.com/elastic/ingest-dev/issues/3637

Logs

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @oakrizan? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v8./d.0 is the label to automatically backport to the 8./d branch. /d is the digit

[oakrizan]

/test

[oakrizan]

/test

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b postmigration-enable-tests upstream/postmigration-enable-tests
git merge upstream/main
git push upstream postmigration-enable-tests

[rowlandgeoff]

@oakrizan Is this related to the test enablement?

[oakrizan]

Yes, since win doesn't have minfrin/retry

[rowlandgeoff]

@oakrizan Is this related to the test enablement?

[oakrizan]

Yes, I've merged it in a separate MR. Will be removed after rebase

[rowlandgeoff]

Higher level question... is this PR still needed? I think you used this to test whether the muted tests were still issues, and then opened individual tickets for the tests that still have problems. So would this PR stay open until all of those tickets are resolved (could be a while), or would those tests be re-enabled by a series of individual PRs? Or am I misinterpreting this, and those failing tests are still muted, but this PR is enabling all of the ones that are passing now?

[oakrizan]

Higher level question... is this PR still needed? I think you used this to test whether the muted tests were still issues, and then opened individual tickets for the tests that still have problems. So would this PR stay open until all of those tickets are resolved (could be a while), or would those tests be re-enabled by a series of individual PRs? Or am I misinterpreting this, and those failing tests are still muted, but this PR is enabling all of the ones that are passing now?

I'd assume it is, it's used as reference (code changes, build results) in issues that were created or moved to beats.
I think it might be helpful to see which PR labels and which code changes are required to make those tests run.