Support item_assets extension's AssetDefinition in raster extension

[jpolchlo]

Related Issue(s):

• Connects Add classification extension #1093

Description:
There is a missing compliance in the raster extension vis-a-vis the item asset extension. It is permissible by the raster extension spec to tuck raster_bands information into the item_assets block on a collection. Raster appears not to support this. In the interest of creating a relatively uniform strategy to query information in collection assets, we may be interested in elevating the item_assets' AssetDefinition to first class status with respect to the raster extension. This PR proposes a change to make that happen.

This connects to the classification extension work because that extension can use the same mechanism.

Notes:

• pystac.extensions.item_assets.AssetDefinition is defined nearly identically to pystac.Asset, with the difference that the former disallows the href field, while the latter requires it. If we could find a smart way to define AssetDefinition as a subclass of Asset, we could possibly entirely eliminate the need for this PR.
• AssetDefinition has no notion of an owner, so it's not currently possible to validate that the collection hosting the asset definition has the raster extension registered with it. We may want to add an owner to this class to improve its expressivity. Again, this would be obviated by proposal in the above comment.

PR Checklist:

• pre-commit hooks pass locally
• Tests pass (run scripts/test)
• Documentation has been updated to reflect changes, if applicable
• This PR maintains or improves overall codebase code coverage.
• Changes are added to the CHANGELOG. See the docs for information about adding to the changelog.

[codecov-commenter]

Codecov Report

Patch coverage: 91.17% and project coverage change: -0.01 ⚠️

Comparison is base (f10a7de) 90.33% compared to head (6f22014) 90.33%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1110      +/-   ##
==========================================
- Coverage   90.33%   90.33%   -0.01%     
==========================================
  Files          48       48              
  Lines        6323     6343      +20     
  Branches      943      944       +1     
==========================================
+ Hits         5712     5730      +18     
- Misses        429      431       +2     
  Partials      182      182              

Impacted Files	Coverage Δ
pystac/extensions/item_assets.py	95.37% <85.71%> (-0.75%)	⬇️
pystac/extensions/raster.py	90.46% <92.59%> (+0.14%)	⬆️

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[jpolchlo]

After in-person discussion, I'll be adding an owner field to the asset definition. Regularizing AssetDefinition with Asset didn't seem to pass the sniff test with @gadomski. Womp womp.

[gadomski]

Regularizing AssetDefinition with Asset didn't seem to pass the sniff test with @gadomski. Womp womp.

I'm probably more of a -0 than -1 on this idea ... I could be on board with trying to share behavior between the two, but I worry about over-abstracting what is really a pretty simple data structure.

[jpolchlo]

I worry about over-abstracting what is really a pretty simple data structure.

Yeah, that tracks. It's easy to enrich asset definitions, so it's not a huge problem. Many extension specs are written with item:assets in there, but many are not. Treating AssetDefinition too much like Asset opens the door to too much "accidental" support for item assets in extensions that didn't mean to have it. Plus the href field is pretty fundamental to Asset-ness, and to not have it is inviting bugs. Let's just leave it out.

[gadomski]

Needs CHANGELOG entry, otherwise LGTM.

[jpolchlo]

This is ready for merge when tests pass.