[RFC] Decouple MMDS service from network stack

[jyliu02]

Changes

• Implemented an vsock-based HTTP server for MMDS.
• Optional MMDS server API and configuration.

Reason

• MMDS traffic is much less frequent than standard network I/O, so it benefits networking-intense application by separating MMDS from the fast data path. And it is acceptable for MMDS to be a bit slower.
• This design simplifies future attempts at vhost-user-net or other data-plane offloading by preventing MMDS from interfering with typical network traffic.
• Modularity & Maintainability: allows independent development of MMDS logic and eases the burden of maintaining the complex Dumbo stack.
• The guest can issue requests via socat directly or using curl by bridging an IP to vsock via socat.

Related to #1761

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

• I have read and understand CONTRIBUTING.md.
• I have run tools/devtool checkstyle to verify that the PR passes the
  automated style checks.
• I have described what is done in these changes, why they are needed, and
  how they are solving the problem in a clear and encompassing way.
• I have updated any relevant documentation (both in code and in the docs)
  in the PR.
• I have mentioned all user-facing changes in CHANGELOG.md.
• If a specific issue led to this PR, this PR closes the issue.
• When making API changes, I have followed the
  Runbook for Firecracker API changes.
• I have tested all new and changed functionalities in unit tests and/or
  integration tests.
• I have linked an issue to every new TODO.

---

• This functionality cannot be added in rust-vmm.

[bchalios]

Hi @jyliu02! Thanks a lot for your contribution! We'd also like to apologise for not responding to your comment. We somehow missed your comment when reviewing open source activity.

That said, this topic is an interesting one for us. We would like to decouple MMDS from the emulation of the network device. However, we would like to think a bit more carefully the available options for doing so.

One thing that we definitely need to consider is backwards compatibility. We have users that already consume the existing MMDS API, that is the one where clients in the guest speak to link-local addresses to interact with MMDS. We simply cannot drop the existing support. In that sense your changes make perfect sense.

However, we still want to discuss a bit internally our options before committing to any given solution. We will discuss this internally and let you know, how we would like to proceed.

[jyliu02]

Thanks for the comment. Backwards compatibility is also my first design consideration. The current design is still sketchy, but I’ll commit to a polished version once we can settle on a direction. Looking forward to further feedback.