chore: Address flaky integration tests

[WhitWaldo]

Description

Especially now that we're adding integration tests to N-2 stable versions + RCs (if any), it means that several of the integration tests are now running against less-optimized versions of the runtime and missing performance test benchmarks or using features not yet supported. This simply adds a skip flag to those tests so they don't run on the older versions as they aren't supported.

Issue reference

We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.

Please reference the issue this PR will close: #[issue number]

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 65.42%. Comparing base (29a34e0) to head (35fe808).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1813   +/-   ##
=======================================
  Coverage   65.42%   65.42%           
=======================================
  Files         296      296           
  Lines        8694     8694           
  Branches     1009     1009           
=======================================
  Hits         5688     5688           
  Misses       2761     2761           
  Partials      245      245           

Flag	Coverage Δ
net10.0	65.41% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[WhitWaldo]

@copilot I'm seeing that the Dapr.Workflow integration tests for 1.15 and 1.16 of the runtime appear to be getting stuck or timing out partway through and there's nothing in the log to indicate which test it might be. Can you please work out which workflow tests did not pass successfully then do an analysis as to which of those might be responsible for hanging so I might flag with them with a [MinimumDaprRuntimeFact("1.17")] attribute?

[Copilot]

@copilot I'm seeing that the Dapr.Workflow integration tests for 1.15 and 1.16 of the runtime appear to be getting stuck or timing out partway through and there's nothing in the log to indicate which ...

I traced the workflow matrix jobs in run 25595974345 and the non-success workflow targets were net8-1.15.14-Workflow, net8-1.16.14-Workflow, net9-1.16.14-Workflow, and net10-1.16.14-Workflow (while 1.17.6 workflow jobs completed). The most likely hang source in the workflow test set is MaxConcurrentActivitiesTests (both ShouldRespectMaxConcurrentActivitiesLimitOfOne and ...LimitOfThree), since they exercise the same max-concurrency runtime behavior family as the already-gated max-concurrent-workflow tests. I added [MinimumDaprRuntimeFact("1.17")] to both tests in commit dc265d5.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• 172.19.0.1
  • Triggering command: REDACTED, pid is -1 (packet block)
• 172.22.0.1
  • Triggering command: REDACTED, pid is -1 (packet block)
• 172.23.0.1
  • Triggering command: REDACTED, pid is -1 (packet block)
• 224.0.0.251
  • Triggering command: REDACTED, pid is -1 (packet block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)