Initialize migration workflow

[Neylix]

Description

This PR aim to initialize the migration workflow.
Each migration needed will be an elixir scripts in priv/migration_tasks according the name to [version]-[description].exs.

There is 2 times when the migration is called:

• before starting the application
• during the execution of an upgrade thanks to the appup file. Migrate function call is automatically added at the end of appup

The migration file in DB always contains the last version the node runned the migrate tool, even if there is no migration to execute

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How Has This Been Tested?

• Unit tests
• Create a new migration script that create a file somewhere. Build a release, start the node, run a hot reload, all the file should have been created

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[bchamagne]

There's something I don't get but that might not be an issue, if there are 4 migrations to catch up, this will do the 4 pre_start one after the other. Is it ok ? Don't you need to do pre_start1 then pre_up1 then post_up1 and only then run pre_start2 then pre_up2, then post_up2 etc. ?

[Neylix]

The case here is that the pre_start is triggered when the node start, and the pre/post upgrade are triggered when the node is currently running and doing an hot upgrade.
When a node is currenlty running it means that it is on the last version, or it will integrate new version one by one (with the governance transactions).
So for a specific version you can run either pre_start or pre/post upgrade but never both.
And in theory the code in pre_start would be the same as pre/post upgrade