Add Azure 2D imagery provider

[lukemckinstry]

Description

Switches on the Azure2DImageryProvider class. Also adds viewport attribution logic for Azure layers.

To Do

DO NOT MERGE until complete

• Change sandcastles to use production asset IDs, and remove links to ion staging urls

Issue number and link

Testing plan

NOTE: Test using ion staging asset IDs until prod assets are ready

Sandcastles (to publish in prod)

To view the sandcastles, add the key to your Ion Staging account.

• Add Azure 2D Data ci-build link
• Imagery Assets available in ion ci-build link

Test both ways to add Azure 2D data

• IonImageryProvider.fromAssetId() - sandcastles 1&2
• Azure2DImageryProvider constructor test sandcastle
  • add Azure key
• Check attribution - satellite map has most attribution
• Test prod ion asset IDs, when ready

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

[github-actions]

Thank you for the pull request, @lukemckinstry!

✅ We can confirm we have a CLA on file for you.

[lukemckinstry]

ready for review @ggetz

[ggetz]

Thanks @lukemckinstry! I did an initial pass on the code and have a few questions and comments.

I will follow up to test this shortly.

[ggetz]

What was the motivation for changing this away from Bing?

[lukemckinstry]

this was missed in the last release for Google imagery. This sandcastle corresponds to and is linked from the imagery tutorial https://cesium.com/learn/cesiumjs-learn/cesiumjs-imagery/ We updated the tutorial and sample code to use Google but forgot to update the sandcastle.

[ggetz]

I ran into this in https://github.com/CesiumGS/cesium/pull/13004/files#diff-8c9bd0da5a2315f5b1211e299d0d1517027f1bf8e7a3eab29a601b6761f548f1R46, but it looks like there is a discrepancy between the docs for Azure2DImageryProvider.ConstructorOptions which specifies a default and the implemented behavior.

In my PR, I implemented the default value. Please let me know if that assumption was wrong.

[lukemckinstry]

good catch, there was a discrepancy, implementing the default is good 👍

[ggetz]

The promise kicked off by this function could reject unpredictably, and that can lead to confusing behavior in isolation, like when called in a unit test.

Ideally, we should not kick off any async processes in the constructor. See how I handled this in https://github.com/CesiumGS/cesium/pull/13004/files#diff-7142af57f22c9916aeeac920512bb9d8211e4a6b769201230de03902b119fa1bR487-R501 and let me know if you have any feedback.

[lukemckinstry]

this makes sense if the requestImage function is a better place for it to fail gracefully, I'll do the same update for Azure2DImageryProvider

[ggetz]

Not strictly required to merge this PR, but I wonder if we can more lazily request tile credits as needed based on the current zoom level, and potentially extents, alongside the image requests in requestImage.

This would also potentially apply to Google2DImageryProvider.

[lukemckinstry]

thanks for the review @ggetz, ready for another pass

[ggetz]

Thanks @lukemckinstry! The updates look good to me from a code standpoint.

I'll do a final testing pass once we merge #13004 and the final asset IDs are in.