0.17: replace code with compatibility imports from 0.18

[bonzini]

Summary of the PR

Allow using code targeting 0.17.x together with vm-memory 0.18. This PR re-packages the code of vm-memory 0.18.0 while preserving API compatibility with 0.17.1. All of the actual implementation comes from version 0.18.0, which this crate re-exports with GuestMemoryBackend changed back to GuestMemory.

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.

[XanClic]

Sorry, remind me, what is the use case for this? Is it that users may stay for at least a while on 0.17.x to keep the old interface, and we may release new 0.17.x versions with updated dependencies to 0.18+? If so, sounds OK, maybe should be noted explicitly in the changelog (that future 0.17.x releases are in the cards).

Specifically for the PR as-is: I see that cargo doc pulls in upstream vm-memory’s documentation (e.g. it does produce GuestMemory documentation as if that were part of this crate, even with --no-deps), which is both good (no missing documentation), but also not ideal, as for example the GuestMemory documentation calls it GuestMemoryBackend and references a GuestMemoryBackendSliceIterator. Some of these links work (e.g. that latter reference resolves to just GuestMemorySliceIterator), others don’t (e.g. GuestMemoryBackend reference in GuestMemory::last_addr()).

It’s not that bad, though, so I don’t think it’s a problem that needs solving if there’s no easy fix.

So my only real problem is that cargo fmt -- --check complains. :)

[bonzini]

Sorry, remind me, what is the use case for this? Is it that users may stay for at least a while on 0.17.x to keep the old interface, and we may release new 0.17.x versions with updated dependencies to 0.18+? If so, sounds OK, maybe should be noted explicitly in the changelog (that future 0.17.x releases are in the cards).

I think we do not need more than one release, because a single 0.17.2 version can work with any 0.18.x version (they are ABI-compatible with 0.18.0 after all).

The advantage is that crates that stay on 0.17 will still be able to interoperate with those that move to 0.18.

[roypat]

heh, why is the "merge" button showing even though CI is failing? 🙈

[bonzini]

Probably the 0.17 branch is not protected.

[bonzini]

Probably the 0.17 branch is not protected.

Fixed (and CI now passes).