check headers for firmware version

[T0biii]

early draft for ngnix totaly untested (just ideas how to use the user agent and the firmware header)

https://gluon.readthedocs.io/en/v2023.2.x/releases/v2023.2.html#important-notes
Upgrades to gluon v2023.2 and later releases are only supported from releases gluon v2022.1 and later

FFMUC (from map):

• v2024.4.2-next (gluon-v2023.2.2)
• v2024.3.2-next (gluon-v2023.2.2)

https://gluon.readthedocs.io/en/v2023.1.x/releases/v2023.1.html#important-notes
Upgrades to gluon v2023.1 and later releases are only supported from releases gluon v2021.1 and later.

FFMUC (from map):

• v2024.1.1 - v2024.4.2 (gluon-v2023.1.2)

the firmware Version header is set to: /lib/gluon/release

grische:

Falls Firmware ohne X-Firmware kommt, dann redirect auf legacy-v2022.5.x
Falls Firmware X-Firmware <v2022.5.8 kommt, dann redirecte auf legacy-v2022.5.x
Falls Firmware X-Firmware =>v2022.5.8 und <2024.8.1 kommt, dann redirecte auf legacy-v2024.7.x
Falls Firmware >=v2024.8.1 kommt, dann redirecte auf stable

[T0biii]

the map function seems to work fine

but nested ifs seems to be a problem, maybe we need another map that checks the Version with Regex and based on this return the right firmware

https://web.archive.org/web/20240215023942/https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/
https://ezecodes.wordpress.com/2016/06/30/multiple-if-conditions-in-nginx/

set $UD "";
   if ($arg_user){
      set $UD T;
   }
   if ($request_method = 'GET'){
      set $UD "${UD}G";
   }
   if ($UD = TG){
   }

[DasSkelett]

I think I got it to work as follows, using another map.
It is not the most elegant solution, you have to do a bunch of regexes to approach the target version step by step (you could condense the regexes per target version to a single one, but I went for the slightly more readable approach and spread it over multiple lines).
Note that as is configured right now, for example a router with firmware v2022.5.6 would first upgrade to v2022.5.8, before going to the next major one - but I believe this is what we want anyway, so we can apply any "pre-migration" fixes.

Also the actual versions are placeholders right now, I don't know whether we actually need the step with v2024.6.1 already? The v2024.7.1 originally mentioned in the PR description doesn't exist.

Testing commands

curl --user-agent "Gluon Autoupdater (using libuclient)" -H "X-FIRMWARE-VERSION: v2018.2.1" -vL http://localhost/stable/manifest
curl --user-agent "Gluon Autoupdater (using libuclient)" -H "X-FIRMWARE-VERSION: v2022.5.7" -vL http://localhost/stable/manifest
curl --user-agent "Gluon Autoupdater (using libuclient)" -H "X-FIRMWARE-VERSION: v2022.5.8" -vL http://localhost/stable/manifest
curl --user-agent "Gluon Autoupdater (using libuclient)" -H "X-FIRMWARE-VERSION: v2023.8.1" -vL http://localhost/stable/manifest
curl --user-agent "Gluon Autoupdater (using libuclient)" -H "X-FIRMWARE-VERSION: v2024.2.1" -vL http://localhost/stable/manifest
curl --user-agent "Gluon Autoupdater (using libuclient)" -H "X-FIRMWARE-VERSION: v2024.6.1" -vL http://localhost/stable/manifest
curl --user-agent "Gluon Autoupdater (using libuclient)" -H "X-FIRMWARE-VERSION: v2024.9.1" -vL http://localhost/stable/manifest
curl --user-agent "Gluon Autoupdater (using libuclient)" -vL http://localhost/stable/manifest
curl -vL http://localhost/stable/manifest

[grische]

I would not use our internal versions as this would require us to update this file every time we do a new firmware release

[grische]

After some pairing with @DasSkelett , we decided to first roll this out in the paths "stable-debug", "testing-debug", ... to avoid accidentally rolling out firmware that impacts all devices.

We also noticed that the next versions were missing, so these have been added as well.

If there are no review issues, this should be ready for deployment.

EDIT: we probably want to squash some of the commits