[r=dimitern],[bug=1067979] state;apiserver: Fix a race - lp bug #1067979
This introduces some changes to how charm store charms are added through the API (in state and to provider storage). Now PrepareStoreCharmUpload is called before trying to download the charm, repackage it and upload it to storage, in order to reserve a charm URL in state with pending state. Added a test that demonstrates multiple concurrent deployments of the same charm does not cause the race issues, like mentioned in the bug.
A few drive-by fixes brought up during review: * Added ReadSHA256 and ReadFileSHA256 helpers in utils, and changed most places where hashes are calculated to use them. * Charms are now uploaded to storage with a randomly generated archive names with the format "<charm-name>-<revision>-<uuid>". This allows multiple concurrent uploads to happen safely, and at the end AddCharm in the API checks to see if the charm info is already updated in state and if so, deletes the duplicated upload. * Added GetEnvironStorage helper to environs/testing. * Fixed potential compatibility issues with older versions and the recently added PendingUpload and Placeholder fields of the charm document.
Also tested multiple concurrent deployments with the local provider manually and updated the bug accordingly.