Is your feature improvement request related to a problem? Please describe.
The current implementation of applying a C8y_DeviceProfile to a set of operations uses the fixed order;

1. firmware
2. software
3. configuration

The concrete use-cases I have are;

1. installing a container-group (software) pulling from a registry that needs a certificate (configuration).
   ==> fails because certificate not yet installed at time of pulling.
2. install a generic software package that needs a valid configuration to work.
   ==> installing package succeeds, running it fails due to missing configuration, restart required (not always obvious to user).

In general it seems that software always depends on configuration and never the other way around.

Describe the solution you'd like
Change the mapping order to;

1. firmware
2. configuration
3. software

Describe alternatives you've considered

The alternatives considered;

• adding workflow scripts to reshuffle the operations order
• wrap otherwise off-the-shelf packages as new packages that include application configuration
• manually installing configuration upfront outside the device-profile
• change applications to deal with temporarily missing configurations

At best these all work, but they typically complicate the system as a whole.

Additional context
The change (swap software and configuration in this function convert.rs) is trivial.
I realize that this breaks behavior for some users and cannot oversee the consequences.
So an option to trigger this new behavior may be desirable.