Simplify in-place refresh component script

[Nguyen Vuong (normanvuong)]

Summary

• Limit in-place manifest refresh to components that can change during apt upgrade or dnf update.
• Preserve install-time versions for pinned and source-installed components.
• Record the active kernel after reboot.
• Keep APT’s native DKMS hook responsible for rebuilding modules in dependency order.
• Simplify refresh logic by removing broad best-effort detection and strict tier handling.

Validation

https://dev.azure.com/hpc-platform-team/hpc-image-val/_build/results?buildId=36810&view=results

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Colton Paul (ColtonPaul)]

The simplification is good, but it does seem like we're losing the confidence that we have a "detector" for components that can upgrade during an in-place upgrade. Is there a compromise option where we get the best of both worlds:

1. We don't have to write version discovery code for components that can't upgrade
2. If the list of upgradeable components in any component_versions.json changes, we're not at risk of forgetting to update refresh_component_versions.sh accordingly?

I'm curious about something like an in-place-upgradeable attribute in versions.json that could help solve this and possibly also help lock down intentions about which package versions can move (for example, I see that pmix still has a detector, so I checked the code and saw that only Ubuntu holds it, and RHEL doesn't. Is that intentional?).