asu: revert sanitize

[map-b]

Since it seems there is no enough review time #1533 and the PR fixing the underlying issue which misleaded to the referenced revert commits has been merged:

• sunxi: image: sync target profiles names with DT compatible openwrt#21095

maybe just reverting to an known working state have better luck.

This would allow to use firmware-selector for the gl-mt2500 MaxLinear PHY case even Owut or Luci ASU app with the workaround of echo "glinet_gl-mt2500" > /tmp/sysinfo/board_name for the MaxLinear users.

The key here, IMHO, is that we have to make clearer the difference between "profile" and "DT compatible string" and for that I am thinking about some variable/messages renames could help also, but in order to prioritize, the code implied in the proposed reverts is the key and I think it goes in opposite direction.
#1525 (comment)
Right now we got this when generating the app.profiles[version][target]

{
'glinet_gl-mt2500': 'glinet_gl-mt2500',
'glinet_gl-mt2500-emmc': 'glinet_gl-mt2500',
'glinet_gl-mt2500-airoha': 'glinet_gl-mt2500',
'glinet_gl-mt2500': 'glinet_gl-mt2500',
'glinet_gl-mt2500-airoha': 'glinet_gl-mt2500-airoha',
'glinet_gl-mt2500-emmc': 'glinet_gl-mt2500-airoha',
'glinet_gl-mt2500': 'glinet_gl-mt2500-airoha',
'glinet_gl-mt2500-airoha': 'glinet_gl-mt2500-airoha'
}
which ends up like this: (not working)
{
'glinet_gl-mt2500': 'glinet_gl-mt2500-airoha',
'glinet_mt2500-emmc': 'glinet_gl-mt2500-airoha',
'glinet_gl-mt2500-airoha': 'glinet_gl-mt2500-airoha'
}

Before commit "sanitize profile" 1579236

{
'glinet,gl-mt2500': 'glinet_gl-mt2500',
'glinet,gl-mt2500-emmc': 'glinet_gl-mt2500',
'glinet,gl-mt2500-airoha': 'glinet_gl-mt2500',
'glinet_gl-mt2500': 'glinet_gl-mt2500',
'glinet,gl-mt2500-airoha': 'glinet_gl-mt2500-airoha',
'glinet,gl-mt2500-emmc': 'glinet_gl-mt2500-airoha',
'glinet,gl-mt2500': 'glinet_gl-mt2500-airoha',
'glinet_gl-mt2500-airoha': 'glinet_gl-mt2500-airoha'
}
which ends up like this: (working only works firmware-selector which use the profile directly, no DTS compatible)
{
'glinet,gl-mt2500': 'glinet_gl-mt2500-airoha',
'glinet,mt2500-emmc': 'glinet_gl-mt2500-airoha',
'glinet,gl-mt2500-airoha': 'glinet_gl-mt2500-airoha',
'glinet_gl-mt2500': 'glinet_gl-mt2500',
'glinet_gl-mt2500-airoha': 'glinet_gl-mt2500-airoha'
}

This do not implies nothing about which of PR fixing the gl-mt2500 issue in the openwrt repo will be finally merged:

• mediatek: filogic: fix supported_devices list for gl-mt2500 openwrt#20632 or
• mediatek: filogic: gl-mt2500 fix compatibles openwrt#20947

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.37%. Comparing base (5e65dec) to head (4ffc3a4).
⚠️ Report is 329 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #1554       +/-   ##
===========================================
+ Coverage   80.75%   92.37%   +11.61%     
===========================================
  Files          15       15               
  Lines         977     1429      +452     
===========================================
+ Hits          789     1320      +531     
+ Misses        188      109       -79     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[aparcar]

@efahl what's your opinion here?

[efahl]

Completely unneeded as the root cause has been fixed upstream in openwrt/openwrt#20632 (which also fixes firmware selector's metadata and re-enables sysupgrade's ability to reject bad images for that profile).

Which reminds me I need to get @hauke to backport it to 24.10 (and 25.12 if it's not already there).

[efahl]

Oh, and I should add that this would restore the bug that caused old LuCI app requests to fail occasionally.

[aparcar]

So I'll close this?

[efahl]

Yes, unneeded.

[map-b]

This has become just bigger that it really is... Can we restart here?

Can we agree that replacing , by _ in parallel that we do the real translation from board_name (usually dts compatible, comma ones) to profile (the underscore ones) is a hack/shorcut which usually matches the actual translation/mapping but is not the rigth thing to do at all? And that we should try to not guess the profile with any "sanitization" and do the real translation/mapping.

@aparcar the only feedback I got from you was this fully delegating, please, can I ask you for a real review? Should I apologize, should I introduce to myself before asking for review? It happens that we are in AI age and my slowly and carefully written, as I am trying to do my best, even for simple PR, are freely marked as IA slop and I am done?

Please, forget the specific gl-mt2500 case. I am just trying to make clearer how ASU handle the device profile identification process which has become really confusing with the "sanitization" here and there. I have looked in all actors: the server and clients. A proposal of "cleaning"(no functional change) in owut efahl/owut#71