Condor rc3

[deuszex]

2.0.0-rc3 compatible. Migration entrypoints for balance and allowance keys to move from old Key formats to new ones (AddressableEntity). Events: EventsMode::CES events included (forked original to update to rc3). EventsMode::Native events included (Casper Native events). EventsMode::NativeNCES (uses both Native and CES eventing). Compiles on latest rust.

Added 1.5.6 fixture(state snapshot) to test migration from 1.5.6 to 2.0.0-rc3.

TODO: Fixture guide/tutorial.

Added entrypoint:

• migrate_user_allowance_keys:
• migrate_user_balance_keys
• migrate_user_sec_keys The above entrypoints change the stored keys from the old style (Key::Hash/Key::Account) to the new one (Key::AddressableEntity) which will be used in the contract going forward. The entrypoints also take events and revert boolean arguments. Supplying false to the events argument turns the eventing off during the current calling of the entrypoint, since the size of the events can be rather large depending on number of arguments provided. Supplying true as the revert argument on the other hand will cause the call to immediately revert upon meeting an error, which may help in determining the point of failure if encountered one.
• change_events_mode (needs testing): to change the events mode without needing to upgrade the whole contract.

[sczembor]

The current approach relies on a user-provided key map, which introduces the risk of errors and could be cumbersome for larger migrations. Also, it doesn't account for potential "race" if the contract is used post condor and before/while the migration process.

I'd like to propose an alternative "on-demand" migration. This approach would:

1. Trigger migration automatically whenever a account or contract (AddressableEntity) interacts with the smart contract.
2. Reconstruct the old key (AccountHash, ContractHash) and transfer the balance, allowances to the new AddressableEntity key structure if the migration didnt already occurred.

This eliminates the need for a manual key map and reduces the risk of errors. While it might add some complexity, I believe it offers a more robust and scalable solution.

I'm happy to discuss it and see your point of view. @deuszex @gRoussac

[deuszex]

@sczembor That is the so collad "lazy migration" that we have discussed already on our meetings on which you are also present, and as I've said on the mentioned meetings, these decision will go through the proper chain of command, when the relevant personnel are available.

[deuszex]

Closing in favour of another PR