nssp patching code

[minhkhul]

Description

Add patching feature to nssp.

One detail that set this implementation apart from most of our other indicators is that nssp data comes in our db as weekly form instead of daily.

Basically, all weekly data coming in to our db has the issue_date column always marked as the first date of the epiweek that the reporting date falls into, rather than the reporting date itself. For example, I query nssp data from our api that was just put into db on July 5th 2024 and got something like this:

geo_value                  signal source geo_type time_type time_value  \
0      54079  pct_ed_visits_combined   nssp   county      week 2022-09-25
**issue**  lag  missing_value  missing_stderr  missing_sample_size  value  \
0  **2024-06-30**   93              0               1                    1   3.27

Note the issue is 2024-06-30 despite this data coming in on July 5th. It's because 2024-06-30 is the start date of epiweek 202427, so any data coming in that week will be marked under that issue date.

Furthermore, the reason why we use this directory format is because of this batch_issue_format implementation in acquisition, which demands folder format to be issue_yyyymmdd including for patches of weekly data.

Fixes

• Fixes NSSP patching script and NSSP patch april 2024 to july 2024 #1998

[minhkhul]

Note: About custom_run flag, non-patch custom run doesn't really exist in nssp like it does in google-symptoms due to the differences in how the two sources handle revision data and how we grab those data. We'll keep the flag in nssp still to maintain consistency and to disambiguate params.json.

[nmdefries]

One issue with generating duplicate data, and a couple clarifying questions.