Increase timeout of kani tests

[bchalios]

Changes

Increase the timeout for kani test from 30 to 40 minutes.

Reason

Some changes that we did in the VirtIO queue in this PR: #4726 pushed kani proofs close to the time limit we set in the CI.

License Acceptance

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
CONTRIBUTING.md.

PR Checklist

• If a specific issue led to this PR, this PR closes the issue.
• The description of changes is clear and encompassing.
• Any required documentation changes (code and docs) are included in this
  PR.
• API changes follow the Runbook for Firecracker API changes.
• User-facing changes are mentioned in CHANGELOG.md.
• All added/changed functionality is tested.
• New TODOs link to an issue.
• Commits meet
  contribution quality standards.

---

• This functionality cannot be added in rust-vmm.

[roypat]

Let's also pass a timeout to utils.check_output (say of 20 seconds less than the timeout applied by pytest), so that if we do get a timeout again, it'll actually print the kani stdout which will tell us what specific harness timed out

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.34%. Comparing base (9e627a7) to head (c633fd0).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4765   +/-   ##
=======================================
  Coverage   84.34%   84.34%           
=======================================
  Files         249      249           
  Lines       27460    27460           
=======================================
  Hits        23160    23160           
  Misses       4300     4300           

Flag	Coverage Δ
5.10-c5n.metal	84.56% <ø> (ø)
5.10-m5n.metal	84.54% <ø> (-0.01%)	⬇️
5.10-m6a.metal	83.84% <ø> (+<0.01%)	⬆️
5.10-m6g.metal	80.91% <ø> (ø)
5.10-m6i.metal	84.54% <ø> (+<0.01%)	⬆️
5.10-m7g.metal	80.91% <ø> (ø)
6.1-c5n.metal	84.56% <ø> (+<0.01%)	⬆️
6.1-m5n.metal	84.54% <ø> (ø)
6.1-m6a.metal	83.83% <ø> (-0.01%)	⬇️
6.1-m6g.metal	80.90% <ø> (-0.01%)	⬇️
6.1-m6i.metal	84.54% <ø> (ø)
6.1-m7g.metal	80.91% <ø> (ø)

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.

[bchalios]

Let's also pass a timeout to utils.check_output (say of 20 seconds less than the timeout applied by pytest), so that if we do get a timeout again, it'll actually print the kani stdout which will tell us what specific harness timed out

Does it make sense to only apply the timeout in check_output then, @roypat?

[roypat]

Let's also pass a timeout to utils.check_output (say of 20 seconds less than the timeout applied by pytest), so that if we do get a timeout again, it'll actually print the kani stdout which will tell us what specific harness timed out

Does it make sense to only apply the timeout in check_output then, @roypat?

If we don't set a pytest timeout, the default of 180s will apply, so we need to overwrite it explicitly :(