Revert RAM load single application commits

[nordicjm]

These commits should not have been merged until after the zephyr 4.0 stablilisation process was complete, a bug has been found which needs to be included in MCUboot for this release, therefore revert the commits so an MCUboot module update can be included

[teburd]

Which bug needs to be included out of curiosity?

[carlescufi]

Next time, why not create a v4.0.0 branch in sdk-mcuboot so that we can cherry-pick fixes there but continue to use main?

[de-nordic]

Next time, why not create a v4.0.0 branch in sdk-mcuboot so that we can cherry-pick fixes there but continue to use main?

I think that MCUboot requires some definition of release management and proper branching for that.
Not only for sdk-mcuboot but for upstream too.

[nordicjm]

The PR was merged by someone that does not follow zephyr releases so was not aware of the zephyr release, it should not have been merged during the zephyr release time. And I'm not fond of creating mirror branches which then deviate from how we use mcuboot in main, for an lts release that's fine or if there is a security fix needed in a still supported version of zephyr but having multiple branches for no reason creates a mess

Zephyr x.x.0 releases should always reference a valid mcuboot commit which is in this repository, point releases may diverge

[carlescufi]

@nordicjm but MCUboot is its own project, I am not sure why the release cadence and cycles of Zephyr, which is one of its users, should influence the state of main in MCUboot.

[nordicjm]

@nordicjm but MCUboot is its own project, I am not sure why the release cadence and cycles of Zephyr, which is one of its users, should influence the state of main in MCUboot.

It is it's own project, the 2 active developers/maintainers are zephyr developers, so the overlap is almost 100%