Add kani in ci + kani proof for conformance to 2.7.7.2 section

[priyasiddharth]

Enable Kani in the CI and add the verify_spec_2_7_7_2() proof to verify that the implementation of queue satisfies 2.7.7.2 requirement. The proof relies on whether the EVENT_IDX feature has been negotiated. Conversely with test_needs_notification() test, this proof tests for all possible values of the queue structure.

Summary of the PR

This is review-ready version of #324 and #339.
First, we add Kani to the CI pipeline with a timeout of 20 minutes. The timeout is essential because Kani converts a rust program to a SAT problem which is NP-complete and may not return in a reasonable time.

Second, we add a kani proof to meet the requirements outlined in 2.7.7.2 of the virtio specification regarding the notification suppression mechanism. We have sketched this proof from the same proof defined for the queue implemented in firecraker. This commit adds the verify_spec_2_7_7_2() proof to verify that the implementation of queue meets 2.7.7.2 requirement. The proof relies on whether the EVENT_IDX feature has been negotiated. Conversely with test_needs_notification() test, this proof tests for all possible values of queue. To run the proof, you can run:

cargo kani

The proof currently passes with kani v0.62.0:

SUMMARY:
 ** 0 of 4880 failed (379 unreachable)

 ** 1 of 1 cover properties satisfied


VERIFICATION:- SUCCESSFUL
Verification Time: 82.47572s

Manual Harness Summary:
Complete - 1 successfully verified harnesses, 0 failures, 1 total.

Requirements

Before submitting your PR, please make sure you addressed the following
requirements:

• All commits in this PR have Signed-Off-By trailers (with
  git commit -s), and the commit message has max 60 characters for the
  summary and max 75 characters for each description line.
• All added/changed functionality has a corresponding unit/integration
  test.
• All added/changed public-facing functionality has entries in the "Upcoming
  Release" section of CHANGELOG.md (if no such section exists, please create one).
• Any newly added unsafe code is properly documented.

[stefano-garzarella]

@priyasiddharth thanks for this PR. IIUC you are re-working a patch initially developed from @MatiasVara, so I think you should add also your S-o-b in the patch.

[priyasiddharth]

Thank you @stefano-garzarella for the taking on the review. I have added a sign-off tag.

[priyasiddharth]

@stefano-garzarella PTAL

[stefano-garzarella]

@priyasiddharth please mention big changes (e.g. you included patch from #339) and the reason after a push. I think that should also be mentioned in the PR description/title.

Also we usually squash new changes in commit, so all the "fix(comment)..." commit, should be squashed in the first commit (you can remove my Co-authored-by, it was just a suggestion while reviewing. As a general rule, a commit in a PR should not change/fix code added in the same PR.

Maybe we can also change the order of the patches, first enable the CI, then add the first test.

[priyasiddharth]

@priyasiddharth please mention big changes (e.g. you included patch from #339) and the reason after a push. I think that should also be mentioned in the PR description/title.

• Mentioned Run kani as part of the CI pipeline #339 and reason
• Added kani note in PR description/title

Also we usually squash new changes in commit, so all the "fix(comment)..." commit, should be squashed in the first commit (you can remove my Co-authored-by, it was just a suggestion while reviewing. As a general rule, a commit in a PR should not change/fix code added in the same PR.

• squashed changes
• Followed rule

Maybe we can also change the order of the patches, first enable the CI, then add the first test.

• done
  @MatiasVara PTAL

[stefano-garzarella]

LGTM, just very minimal comments! Thanks!

[stefano-garzarella]

nit: we can remove this comment, it isn't adding any information more than the following code.

Just a suggestion for the future, use comments more to explain the reason, the "why" of code/configuration or to explain unclear part. In this case the section is very clear and the comment will not add more.

[stefano-garzarella]

nit: try to group dependencies better (e.g. first std inclusion, then external crates):

Suggested change

	use std::mem::ManuallyDrop;
	use vm_memory::MmapRegion;
	use std::num::Wrapping;
	use vm_memory::FileOffset;
	use vm_memory::{GuestMemoryRegion, MemoryRegionAddress};
	use std::mem::ManuallyDrop;
	use std::num::Wrapping;
	use vm_memory::{FileOffset, GuestMemoryRegion, MemoryRegionAddress, MmapRegion};