JSON Parser for Datalinks

[d-giles]

As data becomes available from different cloud providers, some services are including cloud access information in the associated Datalink in JSON format.

This PR adds functionality to the DatalinkRecordMixin and the DatalinkResultsMixin to handle basic parsing of JSON entries in a uniform way. The methods ask for a column name and a key to identify specific entries in the JSON to parse and return, and allows matching other named parameters. The parsed JSON entries are returned in an astropy.Table with added columns to indicate the row of the original Results object to which the row belongs, and the row of the DatalinkResults where applicable.

While JSON entries are non-standard at present, they are not disallowed in DatalinkResults and are currently being included without official standard or guidance. This PR does not impose a standard, but provides a set of convenience functions which facilitate the use of existing data.

[codecov]

Codecov Report

❌ Patch coverage is 90.90909% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.12%. Comparing base (6971214) to head (2afc229).
⚠️ Report is 113 commits behind head on main.

Files with missing lines	Patch %	Lines
pyvo/dal/adhoc.py	90.90%	7 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #709      +/-   ##
==========================================
+ Coverage   84.04%   84.12%   +0.07%     
==========================================
  Files          79       79              
  Lines        8537     8610      +73     
==========================================
+ Hits         7175     7243      +68     
- Misses       1362     1367       +5     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[msdemlei]

Thanks for taking pyVO on this presumably inevitable path. I think we can in principle merge this even before there is any proper agreement on how this should eventually look like.

However, I'd like it a lot better if there were not, for now, a default cloud provider; at least during the prototype phase, people should need to explicitly pass these in.

Also, I'd auto-detect columns based on an invented UCD (meta.ref.cloudstorage, say). If this turns out to work, we can always get it sanctioned. The alternative of using a utype ("adhoc:cloudstorage") could later interfer with obscore (though it really shouldn't). I'd not insist on that, though. If you say "no, I want bespoke column names", you'd have my blessing, too.

But most importantly: please make it crystal clear in the documentation that this is a draft API that is probably subject to change.

[msdemlei]

Sorry for having missed the review request. Not sure how it got lost.

From where I stand, I'm reasonably happy with what I see. I would prefer if someone from another place that uses "cloud" storage had a look at this and agreed this is the way to do it (I'm from Europe and hence am not afflicted); but if other maintainers are fine, too, I'll not stand in the way of merging.

In particular not if this then is accompanied with a short IVOA note that explains how this is supposed to work, how other data providers can adopt it and that shows a few pieces of code based on this.