Refactor DTR warning

[rly]

Motivation

Currently AbstractContainer performs a check for type(child).__name__=='DynamicTableRegion'. While this currently works, it is not ideal to have DTR-specific code in AbstractContainer and it only matches based on class name, not class type. This code is harder to find and does not work well for subclasses of DynamicTableRegion.

In addition, the check is not comprehensive in covering the possible situations in which it is useful. It only checks whether the referred-to table has a parent. The referred-to table may have a parent, but that parent may not have a parent. e.g. in NWB, a PlaneSegmentation may have an ImageSegmentation parent and that ImageSegmentation parent may have a ProcessingModule parent but that ProcessingModule may not have been added to the NWBFile.

See #891 and #885

Checklist

• Did you update CHANGELOG.md with your changes?
• Have you checked our Contributing document?
• Have you ensured the PR clearly describes the problem and the solution?
• Is your contribution compliant with our coding style? This can be checked running ruff from the source directory.
• Have you checked to ensure that there aren't other open Pull Requests for the same change?
• Have you included the relevant issue number using "Fix #XXX" notation where XXX is the issue number? By including "Fix #XXX" you allow GitHub to close issue #XXX when the PR is merged.

[codecov]

Codecov Report

Patch coverage: 91.30% and no project coverage change.

Comparison is base (dd39b38) 88.34% compared to head (9d27cef) 88.34%.

Additional details and impacted files

@@           Coverage Diff           @@
##              dev     #917   +/-   ##
=======================================
  Coverage   88.34%   88.34%           
=======================================
  Files          45       45           
  Lines        9292     9310   +18     
  Branches     2653     2658    +5     
=======================================
+ Hits         8209     8225   +16     
- Misses        765      766    +1     
- Partials      318      319    +1     

Files Changed	Coverage Δ
src/hdmf/common/table.py	85.49% <83.33%> (-0.04%)	⬇️
src/hdmf/container.py	91.60% <100.00%> (+0.05%)	⬆️

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

[mavaylon1]

@rly this slipped by. I'll review today.

[mavaylon1]

@rly what's the difference between parent and container source? Is the source meant to be the root?

[mavaylon1]

This checks if the table being used in the DTR has a source, if it does then pass, if not then it will check the parent for a source (and so on)

[mavaylon1]

Container_source ==> path to the file ==>Does zarrio set container_source (confirm?)

[oruebel]

container_source is set in BuildManager.build . ZarrIO deals with read/write of Builders, but the logic for creating Containters is the same as in HDMF, i.e., HDMF is setting the container_source and the logic to do so is independent of whether HDF5IO or ZarrIO is being used.

[mavaylon1]

This will check to see of the table and the DTR have some shared ancestor, aka check that its in the same file. If not then it'll be an external link and a warning will be thrown but it will be allowed to write. Correct?