docs: fix DNS lookup delay from IPv6 resolver stall

[RyanJHamby]

Changes

Adds a resolv.conf single-request-reopen option to the guest network
setup steps in docs/getting-started.md.

Reason

Closes #5512. The getting-started guide only configures IPv4 networking
for the guest. glibc's resolver still attempts parallel A/AAAA DNS
lookups by default, and on an IPv6-connected host the AAAA query can
stall on host NAT, adding seconds per lookup.

single-request alone only serializes the two queries but keeps them
on the same source port, so it doesn't help when the drop is on the
5-tuple itself, which is the usual case here. single-request-reopen
closes and reopens the socket between the two queries, so the second
query goes out on a fresh source port with a distinct 5-tuple, which
is what actually avoids the stall. This was confirmed as the fix by
the issue reporter, and a maintainer invited a documentation PR for it.

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 checkbuild --all to verify that the PR passes
  build checks on all supported architectures. (N/A — docs-only change, no
  Rust code touched; skipped since it doesn't exercise this change)
• I have run tools/devtool checkstyle to verify that the PR passes the
  automated style checks. (test_markdown_style and
  test_markdown_internal_links both passed)
• 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. (docs-only
  fix to a getting-started walkthrough; please advise if this warrants an
  entry)
• If a specific issue led to this PR, this PR closes the issue. ([Bug] example rootfs incurs 5s DNS lookup delay #5512)
• When making API changes, I have followed the
  Runbook for Firecracker API changes. (N/A — no API changes)
• I have tested all new and changed functionalities in unit tests and/or
  integration tests. (N/A — docs-only change, not applicable to unit/integration
  tests; verified via markdown style checks instead)
• I have linked an issue to every new TODO. (N/A — no new TODOs added)

---

• This functionality cannot be added in rust-vmm. (N/A — this is a
  documentation fix, not new functionality)

[not4s]

Thanks for picking this up,

1. The inline comment is a bit long, I would go with something like

  # glibc resolves A/AAAA in parallel; on an IPv6-connected host the AAAA query
  # can stall on host NAT, adding seconds per lookup.
  ssh -i $KEY_NAME root@172.16.0.2  "echo 'options single-request-reopen' >> /etc/resolv.conf"

2. nit context for the PR: it'd be good to note why single-request-reopen specifically rather than plain single-request. single-request only serializes the two queries but reuses the same source port, so it doesn't help when the collision is on the 5-tuple itself, which is the usual case. single-request-reopen opens a new socket, so the second query gets a fresh source port and a distinct 5-tuple, which is what actually sidesteps the drop.

[not4s]

the IPv6 attempt will stall until it times out reads a bit strong; it's intermittent and kernel dependent, so to me 'can stall' is more accurate.

[RyanJHamby]

Thanks for the review. Updated the comment to your suggested wording.

On single-request-reopen versus single-request: single-request serializes the two queries but keeps the same source port, so if the drop is happening on the 5-tuple, which is the case here, reusing the port does not change anything and the second query still stalls. single-request-reopen closes and reopens the socket between queries, so the AAAA query goes out on a fresh source port with a distinct 5-tuple, which is what actually avoids the stall. I will add this explanation to the PR description as well.