Simplify holding upgrade scenario

[GeorgSchneider]

Following #20 we have tightly coupled an account to a holding type at runtime.

An upgrade scenario for holdings would look as follows:

• introduce V2 holding
• for each V1 holding factory, introduce V2 holding Factory
• for each account referencing the V1 factory, create new account referencing V2 factory
• replace each V1 holding with a V2 holding at the new account

In the above scenario, we end up with two accounts (referencing factory V1 and V2, resp.). Because of the key uniqueness constraint, we are forced to use a different label for each account.

To make it less confusing, we might need to introduce account versioning.

An alternative is to have multiple holding factories per account and

• always Credit using the latest one
• in a Transfer, use Daml exceptions to make sure the correct factory is used (not necessarily the latest)

[matteolimberto-da]

See https://discuss.daml.com/t/daml-finance-account-tight-coupling-with-holdingfactory/6799 for additional limitations of the single holding factory.

[matteolimberto-da]

This item can be considered Done with the version of Daml Finance which is currently in main, where we use

• a single holding factory that can create multiple implementations according to the provided HoldingStandard
• the Account references the holding factory via key
• Debit no longer calls the holding factory but is implemented directly in the Account

A holding upgrade scenario now looks as follows:

• create a new factory and archive the old one
• transfer the holding to self (or simply Debit a Holding and Credit it again)

[johan-da]

I have worked on adding a script for the upgrade today, reflecting exactly this scenario:

archive old factory
create a new factory (using the same key)
transfer the holding to self (or simply Debit a Holding and Credit it again)

Got a PR out to add a Remove choice to the holding factory first, but will add it afterwards.