Consolidate common ASU client functions

[efahl]

@stokito @systemcrash @dannil @mwarning I picked you four as the most frequent committers/enhancers of the ASU client tools; please tag anyone I missed that you think might be interested. There's no expectation being set here, any input is welcome.

@aparcar asked about commonizing various bits of the ASU clients, so here we are.

• Get some sort of ASU server health status up front, avoid all (well, some) of those forum posts and github issues getting logged "the server is down".
• Move package listing and selection into standalone JS, then use that for LuCI app, add it to Firmware Selector.
• Consolidate OpenWrt version selection. Maybe with switches to show snapshots and/or RCs?
• More consistent "build monitor" output, add some output for when things hang (again, avoid all the posts and issues about "it gets to validate image and stops").
• More...

owut looks for package build failures, which it then uses to say, "you have this package installed but the packge-build is broken, you cannot request a build at this time." Does that seem a good thing to bring out everywhere? (owut currently scrapes the html from, for example, https://downloads.openwrt.org/snapshots/faillogs/x86_64/ then looks into each directory on a per-target, per-feed basis, I'd really, really like to get some json in there. efahl/owut#5)

[systemcrash]

• Get some sort of ASU server health status up front, avoid all (well, some) of those forum posts and github issues getting logged "the server is down".

There are zillions of ways. A simple POST request with a 10 second timeout? It's the poor-man's status check when server-side monitoring is absent.

• Move package listing and selection into standalone JS, then use that for LuCI app, add it to Firmware Selector.

Client side? Should be easy enough.

• Consolidate OpenWrt version selection. Maybe with switches to show snapshots and/or RCs?

Lots of users like to live on the edge - flags for those are good. I don't think this differs much from how things work today. What did you have in mind here?

• More consistent "build monitor" output, add some output for when things hang (again, avoid all the posts and issues about "it gets to validate image and stops").

• More...

What's missing? A static count-down is probably sensible, unless you are able to gather 95th percentile statistics of how long most server-side operations take. But statistics quickly explodes into monitoring and saving data. Stats are only mostly good post-factum.

owut looks for package build failures, which it then uses to say, "you have this package installed but the packge-build is broken, you cannot request a build at this time." Does that seem a good thing to bring out everywhere?

As a last choice. Depends if other packages depend on that one package. It may complicate the code-path a bit, but I prefer offering to 'try to proceed anyway'. The challenge here is not re-inventing the package management system to figure out how key the dependency was. Ask the user to try again with a new selection, or propose a new selection.

"Trying anyway" isn't about giving out poor quality product, it's about managing human expectations. "You'll have a half-broken piece of shit, but it'll work, or you can wait until the package is fixed". Some users really need something in a pinch. Package management should fix the missing bits later.

This one will cause problems: when builds update, I've tried refreshing my package lists, a package should be there, but it's already been superseded, just not yet updated in the index. It's rare, but I've hit it.

JSON might simplify this, but how should the build process emit JSON? Why not just look at the presence of folders there? I guess walking the tree is an expensive operation. Perhaps the download server itself can summarise in JSON or RSS, or, at worst, REST.

[dannil]

Get some sort of ASU server health status up front, avoid all (well, some) of those forum posts and github issues getting logged "the server is down".

Having a /status or /health endpoint is quite standard on backends (at least the industry I work in) which we can extend in the future with custom messages, in addition to just getting a non-response when it's completely offline. We can also use this in the apps to short-circuit any functionality that requires a connection to the asu server (for example requesting a custom build from the Firmware Selector) which isn't present today, now the process halts after the user has requested a build instead of before.

EDIT: or, in the case of the LuCI app, gets stuck on a loading spinner after clicking "Search for firmware upgrade" if the server is down, without any feedback to the user, so there it doesn't even halt.

Move package listing and selection into standalone JS, then use that for LuCI app, add it to Firmware Selector.

Do we have a way to distribute this standalone JS to the different apps if the implementation changes? Or maybe I've understood this point.

Consolidate OpenWrt version selection. Maybe with switches to show snapshots and/or RCs?

Since users already can select to upgrade to SNAPSHOT, allowing release candidates seems like a straight-forward idea since these are anyway more stable than SNAPSHOT.

[mwarning]

@efahl it would be nice to have some ASU client code in a common file/place like an asu.js that can be used for the openwrt-firmware-selector. As long it pulls in no additional dependencies and is small.

If someone likes to do this, please do. But keep me in the loop. That avoids confusion afterwards.