Backport of website: Upgrade <Subnav /> & <ProductDownloadsPage /> into release/1.9.x

[hc-github-team-secure-vault-core]

Backport

This PR is auto-generated from #13470 to be assessed for backporting due to the inclusion of the label backport/website.

WARNING automatic cherry-pick of commits failed. Commits will require human attention.

The below text is copied from the body of the original PR.

---

🔍 Preview Link

---

This PR upgrades the <Subnav /> and <ProductDownloadsPage /> components on the Vault website to their latest versions.

[hashicorp-cla]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

---

temp seems not to be a GitHub user.
You need a GitHub account to be able to sign the CLA. If you already have a GitHub account, please add the email address used for this commit to your account.

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[EnMod]

Unsure of why this cherry-pick would have failed 🤔

[mladlow]

We're still working out some rough edges with backport-assistant.

[EnMod]

Thanks for the context @mladlow 👍

[mladlow]

Hey @EnMod, we think we're making progress on the backport assistant issues we're having, but we'll likely need to either force push this PR or close this and manually cherry pick the changes since the automated cherry pick failed.

[EnMod]

Got it @mladlow , can do. Thanks for the heads-up 👍

That said, going to close this out in favor of manual cherry-picking.

[EnMod]

@mladlow For future PRs, do you advise against using the backport assistant until the issues are solved?

[mladlow]

I think we should keep using it. It works some of the time, and if it doesn't work, presumably one would have needed to do the manual cherry pick anyway, since the plan was to backport? That is my reasoning anyway.

The problem that we're having is when backport PRs aren't merged to 1.9 quickly the automatic cherry picking is more likely to fail, so we get progressively more of the "no-op commit due to failed cherry-picking" PRs (at least that is the theory, unclear why this one failed to cherry pick).

[EnMod]

Ahhh ok, thanks for the context here. I think your reasoning is sound 👍