adds revises downloads page, adds package page, updates package data

[stockholmux]

Description

This revises. the downloads page extensively.

1. Updates to the package manager information at each version
2. Adds a page with grid of versions and package managers.
3. Moves the artifact_source from each release files to a central data file since it never changes

Screenshots:

Package Manager page:

New section on downloads and each release:

Issues Resolved

#131

Check List

• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the BSD-3-Clause License.

[madolson]

Do we really want to be maintaining that dot array? I suppose either:

1. Can we just indicate the minor versions supported. I think that is what is the most useful for what end users support and dramatically reduces the frequency of updates.
2. I wonder if we should just merge it into the Package manager table. Add in the notes, "known support for 8.0".

[stockholmux]

@madolson I do think it's necessary: the gap it fills is that our release pages show the places you can get a given version; I think that's reasonably required information. However, because some package managers lag considerably (e.g. Ubuntu currently only has 7.2.5), looking only at a single version could lead someone to believe that Valkey isn't available in a given package manager.

Originally, I did consider having this information only appear on the release page with a row for each distro and the last version supported. However, this got very complicated to present multiple version lines. The dot array, IMHO, is the easiest way to represent the entire landscape.

Also, the dot table is actually just a representation of the same data in the package manager table, so it's no extra maintenance is needed, new package managers automatically appear on this table as soon as they are added to any version.

[stockholmux]

I've been investigating the maintenance concerns raised by @madolson.

A lot of this is source from repology we can build up the data using their API and put it into a GitHub Action. Tinkering that I was able to pull the data:

import asyncio
import repology_client
import json


async def main():
    packages = await repology_client.get_packages(project="valkey")
    for package in packages:
        print("---")
        print(package.repo.split("_")[0])
        repo_remainder = package.repo.split("_")[1:]
        print("_".join(repo_remainder))
        print(package.version)
        
asyncio.run(main())

This PR relies on getting the availability of Valkey in particular package managers where as repology returns repos with their latest version. It just needs a little extra to transform the data.

[avifenesh]

@madolson @zuiderkwast Is it relevant? Should I try to embed it?

I'm not sure if we can make it look nice as it is now, it will be parsing from json to md, then embed the dynamic md as a code block, complicating the status, but feasible.
A lot of the packages on those sites are deprecated, non-official, backports, and we should also add filters to the parsing, and check all kinds of parameters (is it alpine stable? Which version of the distro? Is it a real package, or just named valkey and empty? 8 include the patches? Does it include valkey-cli? Official? And so on...).
The best thing to do, is put a bit of responsibility on users and point clearly that while we're explaining how to do, they should go and check if to do.
I find the idea of trying to maintain problematic, as it may lead to users over-trust the site resources and avoiding checking (which is an easy thing, just go to the link and check your distro so it's not a bad UX).

But if it's relevant, I can take it.

[zuiderkwast]

@avifenesh We could use a badge from repology instead? Then we don't need to update it ourselves...

[![Packaging status](https://repology.org/badge/vertical-allrepos/valkey.svg)](https://repology.org/project/valkey/versions)

It renders like this:

[avifenesh]

@zuiderkwast Yes, that looks good, actually. We can leave the instruction of how to, and just add those tags. So it's visible in the same place.
Need to see how to make it more fitted for the site, a grid, or something, but yes, that's good, and not logic and parsing needed.

[madolson]

@avifenesh I kind of think we should just put this badge at the bottom of the page with a link.

[avifenesh]

I thought about something like that, but I didn't check if the Zola and the tool the site is being built with will give this option.

[madolson]

That looks fine to me.