Fix merging of composite availability

[emackey]

Fixes #7717

The name and availability weren't being cleaned by the CompositeEntityCollection's clean helper, so re-merging them wasn't taking place by order of composed collections, instead it was whatever the order that the underlying collections were being populated by the server, which was a race condition.

At some point, the merge for availability had intentionally been installed backwards, possibly as a workaround for this race condition in a particular app.

[cesium-concierge]

Thanks for the pull request @emackey!

• ✔️ Signed CLA found.
• ❔ CHANGES.md was not updated.
  • If this change updates the public API in any way, please add a bullet point to CHANGES.md.
• ❔ Unit tests were not updated.
  • Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

• Cesium Viewer works.
• Works in 2D/CV.
• Works (or fails gracefully) in IE11.

[emackey]

I need to fix the merge tests, they test for the bad behavior.

[emackey]

I added a new test to ensure that availability cleans & merges correctly like the other properties. The new test succeeds here and fails in master (with master showing the lowest-priority collection's availability is the winner in that case).

I also modified one other test in a way I'm less certain of. This test specifically tested for merge to treat availability the opposite way from everything else, and here I've modified the test to treat it as a normal merge, so availability aligns with the other merged properties. I strongly suspect that this intentional backwards-ness was placed there as a workaround for the bug where clean didn't clean the availability.

Ultimately, in master, the chosen availability for any one entity doesn't come from the ordering of collections in the composite at all. Due to the lack of cleaning, it comes from the order in which the collections happened to be first populated in the composite. On this branch, the availability gets cleaned and merged in the same order as all the other entity properties, so it will come from the same source that provided the time-dynamic properties, which seems like a good thing.

It would be great for this to sit in master for a while, to get some testing. I've done my own testing where I intentionally defer loading one collection or the other, and it's clear that master has a race condition there that is fixed here.

[emackey]

The Travis fail is unrelated to tests on this branch. This is ready.

[emackey]

@mramato Any chance you can take a look at this?

[mramato]

Sorry for the slow roll here @emackey. This looks like a straightforward fix and I'm sure if there was a good reason it was flipped (spoiler alert, probably not) we'll be reminded of this soon enough. Thanks again!