show std-replacements & rustsec "unmaintained" in topbar

[syphar]

This is now a new approach for our integration with std-replacements and rustsec.

I still feel like it could be smaller, but also I want test coverage / testability to a certain extend, which enforces some design decisions.

Most important changes:

• we only refresh the data in a scheduled task , right now once an hour
• I ignore any remote cache headers
• for now, the web handler caches for 10 minutes. This can be more, even forever at some point (when we then invalidate precisely)
• For rustsec, we now just use the "standard" local git repository as source. It will be fetched in the scheduled job. rustsec::Database loads everything into memory on open anyways.
• Instead of RwLock or something like that, ArcSwap is much better for our use-case. I hope you can excluse the additional dependency :)

old description

Here we start showing _crate warnings_ in the topbar.

First is the std-replacement data, and rustsec "unmaintained" warnings.

For both we have a source on github pages, which is heavily cached, and also provides a TTL in the response. So my approach here is to fetch both data sources for the crate, generate the html partial, and set the caching headers in fastly based on the cache TTL responses from gh pages.

85% of docs_rs_reqwest is pretty standard but reduced browser / caching behaviour, but there is no usable crate in the wild that is not alpha, so I rebuilt the logic to some point. Exception from standard logic is caching of 404s even when github doesn't return a caching header for us.

To parse the rustsec response, we could use the rustsec library, but the structs don't provide the necessary accessors, and the osv-export feature pulls in gix, which we don't need and is huge). So I copied the structs as we need them for now. The logic when to show "unmaintained" and when not is coming from crates.io itself. There seem to be some progress in rustsec/rustsec#1710, let's see when that is released. Then I'll just switch back.

For std-replacements, I'll start by fetching all.json and just returning the crate that is asked for. Since we cache the thing, that's not too big of an issue. I'll see if we can also generate per-crate json files in gh pages later. This is also what crates.io is doing at the moment, every browser fetches the whole all.json, and then filters for the current crate. ( at the moment it's 3k compressed).

Since we only use that thing in one place / handler, I didn't invest time into adding mock / test clients to the std-replacement/rustsec libraries, for now. Of course t hat increases the amount of tests in handlers::status and implies the need for http mocks.

first UI draft

suuper basic. When both (unmaintained & std replacement) woud be active, I'm showing another element in the topbar.

First draft of the rendering, happy to take ideas? or help?

[syphar]

r? @GuillaumeGomez ready for a first review I think.

frontend wise : i would totally use it like this, but if you want we can also iterate on other approaches :)

[syphar]

@GuillaumeGomez fyi:

having slept over it I think I can simplify this quite far. I also checked how many advisories there are, and std-replacements, and that changes the game.

[syphar]

@GuillaumeGomez ready for a next round

[rustbot]

☔ The latest upstream changes (possibly #3558) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.