bc: backup feature is not working as expected

[Stezido]

Description

Sometimes the exported backup cannot be restored due to an invalid hash. The hash of the multichain directory is created by the blockchain project when the backup endpoint is called. The hash is stored in the metadata.yml file inside the tar'ed backup file. When trying to restore the backup the hash of the backup multichain directory is calculated again and is compared to the directory hash saved in the metadata.yml file. This hash seems to be incorrect sometimes?

The bc endpoints GET/POST /chain should be checked again.

[georgimld]

This problem happens when the hash stored in the metadata.yml file during backup is not the same as the hash that is being calculated during restore, so it is recognised as an invalid trubudget backup. The problem could either be in the creation of the metadata file, when the hash is generated, or when the new hash is created, in the restore feature. I believe that the hash in the metadata.yml file is the one that is invalid, because some backup files can never be restored and always lead to this problem. I didn't find a connection between a certain blockchain instance and this issue, seeing as the feature sometimes works (most of the time) and sometimes doesn't, on the same blockchain, without it being restarted and/or altered in some way.

[Stezido]

Implemented a workaround in #548
The issue is postponed to Milestone 2.0.0 since the way we hash/zip the Chain is inconsistent.
If we change the hash/zip function, backups made with earlier Trubudget versions wouldn't be useable anymore so the change is a breaking one.

[galethil]

Issue with hashing was resolved by replacing MD5 hashing with SHA256 hashing and skipping of metadata.yml file from hash. Implementation done in issue #693
Old backups are still valid, since restore backup endpoint is accepting both MD5 and SHA256 types of hashing. New backups are created only with SHA256 hashing.