Fix misinterpretation of byte order of blocks stored in FITS files

[eslavich]

This PR fixes an issue with reading binary blocks stored in FITS files.

When astropy reads data that requires scaling, it performs said scaling and returns the result in native byte order. Until now asdf has been assuming that all data from a FITS file is big-endian, since that's how the bytes are stored on disk, but due to the scaling operation that's not always the case.

The fix is to accept that the dtype reported by an array from a FITS file is correct.

CC @stscieisenhamer

[codecov]

Codecov Report

Merging #810 into master will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #810      +/-   ##
==========================================
+ Coverage   94.26%   94.27%   +0.01%     
==========================================
  Files          42       42              
  Lines        4971     4980       +9     
==========================================
+ Hits         4686     4695       +9     
  Misses        285      285              

Impacted Files	Coverage Δ
asdf/block.py	96.46% <100.00%> (+0.01%)	⬆️
asdf/fits_embed.py	92.80% <100.00%> (+0.15%)	⬆️
asdf/tags/core/ndarray.py	94.00% <100.00%> (+0.04%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ad141da...24f969d. Read the comment docs.

[stscieisenhamer]

FYI: I tested on the case that prompted the issue report and it does fix the issue.

[perrygreenfield]

Well, this gives me a chance to review a part of the code I've never looked over before. Using this trickery of ASDF redirecting its blocks to FITS extension data sections makes me a bit queasy, not that I have better suggestions (though I wonder if making the FITS references more explicit and requiring manual data extraction might have been a better thing; but I haven't really thought about it).

I wonder why it took this long to find the problem. Seems like any access of raw data would have triggered this. I'll ask Jonathan.

[jdavies-st]

I suspect this was hidden because jwst is the only package that writes ASDF to FITS files, and there was a bug in jwst.datamodels layered on top of it that also munged the unsigned ints that @eslavich fixed a year ago.

spacetelescope/jwst#3680

[perrygreenfield]

Yeah but it has been doing that for a while. Did the jwst.datamodels bug actually counteract the ASDF bug? (so two wrongs do make a right?)