Fix appup removal order

[garazdawi]

This PR makes it possible to do release upgrades with an application replacing which applications it depends on.

One problem remains and that is that the new dependency is started after processes are resumed in the upgraded application.

[garazdawi]

Doing this turned out to be much harder than I thought it would be. Basically, in order to handle this, the systools_relup dependency management engine has to be rewritten as it cannot represent what we want to do. So I'm closing this PR until I or someone else has time to work on it.

[lrascao]

I'm curious on the nature of the blocker, could you provide a high level explanation of it please?

[garazdawi]

The problem is that the primitive instructions used within systools to manage dependencies do not include enough information to do this type of relup. There needs to be a way to make module addition and deletion depend on application start/stop instructions. Also the digraph used to calculate the module purge/load dependencies does a bunch of assumptions that do not work when you try to replace a dependency.

It is not an impossible problem to solve I just don't have the time to solve it right now.

The testcases that I could not make pass are system -> upgrade_SUITE:major+ancient.

[lrascao]

👍 thanks for the explanation

[zmstone]

I'd be happy with only this change:

- { RUs ++ RU0s, W0s}.
+ { RU0s ++ RUs, W0s}.

Does ^ this break some existing tests or some assumptions made somewhere ?

[garazdawi]

I'd be happy with only this change:

- { RUs ++ RU0s, W0s}.
+ { RU0s ++ RUs, W0s}.

Does ^ this break some existing tests or some assumptions made somewhere ?

I don't think it breaks anything, but it doesn't fix it for all scenarios either. Only doing this change feels like putting a bandaid on the problem, though I suppose it may be a step in the right direction.

[zmstone]

I'd be happy with only this change:

- { RUs ++ RU0s, W0s}.
+ { RU0s ++ RUs, W0s}.

Does ^ this break some existing tests or some assumptions made somewhere ?

I don't think it breaks anything, but it doesn't fix it for all scenarios either. Only doing this change feels like putting a bandaid on the problem, though I suppose it may be a step in the right direction.

Can we at least do this (and only this) in this PR ?.

[garazdawi]

I'll put it in test and see if it breaks anything.

[CLAassistant]

All committers have signed the CLA.

[garazdawi]

All tests passed. Merged for release in OTP-23.3.

Fixes https://bugs.erlang.org/browse/ERL-1410