Additional fixes to trending.py

[Skyhawk172]

There are multiple fixes folded into this PR, all related to our trending plots.

I noticed an issue in webbpsf.trending.wfe_histogram_plot when plotting arrows, where the original hardcoded offset does not scale properly when the ylimits change (say, when we change the start and end dates). See screenshot:

This PR addresses this issue for any ylimits, as demonstrated below. The correction arrows now go from the edge of the two connecting points, without overlapping with the points:

There are also a few additional fixes that I've stumbled upon over the last months.

[codecov]

Codecov Report

Patch coverage: 5.33% and project coverage change: -0.45% ⚠️

Comparison is base (2e17f9e) 55.20% compared to head (58db3c3) 54.75%.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #688      +/-   ##
===========================================
- Coverage    55.20%   54.75%   -0.45%     
===========================================
  Files           16       16              
  Lines         6380     6436      +56     
===========================================
+ Hits          3522     3524       +2     
- Misses        2858     2912      +54     

Files Changed	Coverage Δ
webbpsf/trending.py	4.51% <5.33%> (-0.07%)	⬇️

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

[Skyhawk172]

Here's an example of what the PID argument allows:

[Skyhawk172]

Tests are failing because the last commit requires the import of astroquery

ImportError while loading conftest '/home/runner/work/webbpsf/webbpsf/webbpsf/conftest.py'.
webbpsf/__init__.py:96: in <module>
    from . import trending
webbpsf/trending.py:10: in <module>
    from astroquery.mast import Observations
E   ModuleNotFoundError: No module named 'astroquery'
ERROR: InvocationError for command /home/runner/work/webbpsf/webbpsf/.tox/py39-legacy-test/bin/pytest (exited with code 4)

[obi-wan76]

@Skyhawk172 as you work on this, can you also include #677 in this PR? We can iterate on what makes more sense in the trending figure.

[Skyhawk172]

Already done, along with #683.

[BradleySappington]

The code itself looks fine. I do see a lot of magic numbers in there without comments explaining why that specific number is chosen. You can also "duck type" the numbers as implied constants (all caps) and give them meaningful names to make the calculations more legible. Lots of these numbers happen with the offsets calculations, and set_ylim/get_ylim.

These changes aren't necessary, but make reviews easier and the code more legible/maintanable. I'll approve and leave it up to you if you'd like to change.

[BradleySappington]

Looks like #690 should fix these failing tests

[BradleySappington]

@Skyhawk172, would you please do another rebase to verify all tests pass? Need #704

[Skyhawk172]

I merged the latest develop branch, including #704, and only the Sphinx doc build is reporting errors now.

[Skyhawk172]

This PR was closed but not merged. I reopened it so I could merge the latest develop with #708, which should fix the Sphinx test. Then it'll be good to merge.