Update VIIRS L1b reader to use additional netcdf attributes

[simonrp84]

The VIIRS L1b reader (NASA format VIIRS data) misses some netCDF attributes that may be useful to users. This PR adds those attributes: The day/night flag (Day, Night or Both) and the starting plus ending orbital direction (Ascending or Descending). I also added a test to make sure the attrs are being read.

• [x] Tests added

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 96.20%. Comparing base (3a7d0d9) to head (a8418d2). Report is 362 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2891   +/-   ##
=======================================
  Coverage   96.20%   96.20%           
=======================================
  Files         393      393           
  Lines       56781    56787    +6     
=======================================
+ Hits        54628    54634    +6     
  Misses       2153     2153           

Flag	Coverage Δ
behaviourtests	3.81% <0.00%> (-0.01%)	:arrow_down:
unittests	96.30% <100.00%> (+<0.01%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

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

[coveralls]

Pull Request Test Coverage Report for Build 14635749414

Details

• 6 of 6 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.001%) to 96.312%

---

Totals
Change from base Build 14634732700:	0.001%
Covered Lines:	54889
Relevant Lines:	56991

---

💛 - Coveralls

[mraspaud]

While I'm fine with this as a short term solution, I think this is yet another case of the readers maybe being too restrictive/inflexible for what some users really want. Or rather, it forces us to draw the line on what satpy readers really are. Are they generic readers that provide all the information from the files in a semi-standard way? Or do they provide only the information that is shared between all (most) Satpy readers (the data + common metadata)?

If you ask me, I think we should provide everything that is in the file

Side question: Should the orbit information go in an orbital_parameters sub-dictionary like we do for lon/lat/alt information: https://satpy.readthedocs.io/en/stable/reading.html#orbital-parameters

I think it’s fine like it in now.

[mraspaud]

@djhoese ok to merge this?

[simonrp84]

OK @djhoese I've now modifed the PR and it should comply with your request for the orbital_parameters!

[simonrp84]

OK @djhoese I have updated the docs :)