Shared ConsolidatedCalamari Library solution + roundtrip test

[rain-on]

Contains 2 changes:

1. Include a "round-trip" test which proves consolidated zip extracts to zips matching originals
2. All consolidation logic lives in calamari - see following.

At the moment the index.json in consolidated calamari contains a list of hashes (aka directories) which must be consolidated in order for a given flavour of calamari to execute.

Thus when octopus is trying to construct a calamari to run, it copies ALL files from each of the listed directories into a single zip (with pathing) - and sends that over to the target.

Up until now, that works correctly.

As part of the migration to netcore - AzureWebApp required a "shim app" to wrap the capabilities in Microsoft.Deployments.Web (which does not have a netcore counterpart) - this shim-app is a netfx app - and uses newtonsoft.

When a consolidated calamari is created - the AzureWebApp now list in its hashes:

• Directories containing required files for the netcore capabilities
• Directories containing required files for the shim-app.

Unfortunately, this means that Newtonsoft is pulled in 3 times:

• 👍 Once, in root directory for netcore
• 👍 Once, in shim-app subdirectory for netfx
• 👎 Once again in root directory, due to nature of "copy everything in hash-dir"/.

Thus - the netcore version of newtonsoft in the root-directory is overwritten with the netfx version - meaning Calamari.AzureWebApp fails to start when it is reconstructed from a consolidated calamari.

================

The solution is to replace the hashes, with a full-blown file-reference (See example below).

NOTE: Linux path separators are used as they are valid cross platform.

{ "Packages": { "Calamari": { "PackageId": "Calamari", "Version": "27.3.5-pullrequest1416-0029", "IsNupkg": true, "PlatformFiles": { "netfx": [ { "Source": "0bb288e5dfefd00cf8dd53e282a3fb6f/Calamari.nuspec", "Destination": "Calamari.nuspec" }, { "Source": "d712a5a82a446086443ce00b610d8a5d/System.Data.Common.dll", "Destination": "Cloud/System.Data.Common.dll" }, { "Source": "33b8972fa6b00b8922210ca95e5745d1/System.IO.Compression.dll", "Destination": "Cloud/System.IO.Compression.dll" }, { "Source": "bc1215a36bcb4bb151194af2fd6bd8eb/System.Memory.Data.dll", "Destination": "Cloud/System.Memory.Data.dll" }, { "Source": "55d9528d161567a19dbb71244b3ae3ce/System.ObjectModel.dll", "Destination": "Cloud/System.ObjectModel.dll" }, { "Source": "e1e2239979b853157ba75310fea7e65d/System.Runtime.Serialization.Json.dll", "Destination": "Cloud/System.Runtime.Serialization.Json.dll" }, { "Source": "d40515a84448b91315f956e6d1a6c64b/System.Text.Encoding.Extensions.dll", "Destination": "Cloud/System.Text.Encoding.Extensions.dll" },

[flin-8]

Driveby: why do filenames need to be sanitized?

[rain-on]

this can be done better - basically - whenever we see a hash - we want to replace it with a fixed tag.