Update docs with Anza logo

[willhickey]

Problem

Agave docs (docs.anza.xyz) still have Solana Labs branding (#3824)

Summary of Changes

• Update the logo and favicon
• Update page title and copyright

Note: There are several other files that contain old logos in docs/static/img:

android-chrome-192x192.png
android-chrome-512x512.png
apple-touch-icon.png
favicon-16x16.png
favicon-32x32.png
logo-horizontal-dark copy 2.svg
logo-horizontal-dark copy.svg
logo.svg

It's not clear to me if any of these are actually used. They're not referenced anywhere in the repo, but maybe Docusaurus uses them somehow. After this PR is merged and published to edge.docs.anza.xyz I'll see if they show up anywhere on the site. After that I will either update them or delete them in another PR.

Fixes: #3824

[willhickey]

Hey @yihau, is there any reason we can't publish PRs that modify docs on vercel? If we used a different project name each time (eg PR-<number>) then I think updating the logic in build.sh and capture the PR number in publish-docs.sh should work. We'd get a new vercel project for each PR. Those projects wouldn't have anza DNS records but they'd still be accessible from the Vercel dashboard.

[yihau]

is there any reason we can't publish PRs that modify docs on vercel?

I assume you're referring to the PRs' deployment preview, I guess we just not use it. imo, we can enable this feature.

If we used a different project name each time (eg PR-) then I think updating the logic in build.sh and capture the PR number in publish-docs.sh should work. We'd get a new vercel project for each PR. Those projects wouldn't have anza DNS records but they'd still be accessible from the Vercel dashboard.

I think we can enable the vercel feature directly like https://www.github.com/solana-labs/explorer/pull/416 instead of creating many different new projects 🤔

[steviez]

I think we should also consider this PR for BP so that the published docs at https://docs.anza.xyz/ get the update soon vs. when we cut new branches such that this commit is in beta branch

If I recall correctly, going to beta (2.1) should be sufficient, but someone should double check me there 😄

[mergify]

Backports to the stable branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule.

[mergify]

Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis.

[willhickey]

I think we should also consider this PR for BP so that the published docs at https://docs.anza.xyz/ get the update soon vs. when we cut new branches such that this commit is in beta branch

Yeah good call

If I recall correctly, going to beta (2.1) should be sufficient, but someone should double check me there 😄

beta gets published to https://docs.anza.xyz/ and https://beta.docs.anza.xyz/. Stable branch gets published to https://stable.docs.anza.xyz/. I'm opening BPs for both branches to keep all domains the same. We'll see if the BP Reviewers agree :-)

[steviez]

We'll see if the BP Reviewers agree :-)

Ha, I'm obviously in favor of it so feel free to tag me in those BP reviews once CI is passing