Use equivalent item values to find existing property GUIDs

[mrdavidlaing]

Related to #502, this addition extends the decorating collection with guid logic to associate collection item guids with items that have equivalent item.

For example (see test); if the following item exists in an OpsMgr Property Collection:

  { 
    "guid": "28bab1d3-4a4b-48d5-8dac-two",
    "another_property": true,
    "a_property": "\"value\" of 'second' item"
  }

And an operator uses om configure-product to "update" that property with no changes (as might be the case in a GitOps workflow):

  { 
    "a_property": "\"value\" of 'second' item"
    "another_property": true,
  }

om configure-product will decorate the updated property with the guid of the existing equivalent item (ignoring key order); which would register (correctly) as a no-op change by the om bosh-diff functionality; preserving the existing item guid

This partially addresses #207

Known issues

• Does not associate GUIDs for collections that have a secret field AND no logical key

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.

The labels on this github issue will be updated when the story is started.

[mrdavidlaing]

In the tests I needed to unmarshal JSON using both the json and yaml packages in order to faithfully simulate the behaviour of om/api/staged_products_service.go

Out of interest why does Api.GetStagedProductProperties use yaml.Unmarshal() rather than json.Unmarshal()?

[kcboyle]

No particular reason. We inherited this codebase from the releng team, and haven't made everything consistent yet

[mrdavidlaing]

Good to know.

My 2c - we should switch to json.Unmarshal; since it produces more usable map[string]interface{} interfaces.

[kcboyle]

This looks good to us. Stylistically we don't see any problems. We're going to merge in and test. Thanks for the PR!