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

[nmdefries]

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

[nmdefries]

This looks good to me. The only required change before merging is moving the hostname to a param and not including it in the actual template.

[nmdefries]

suggestion (optional): You could wrap this section in a with ssh.open_sftp() as sftp: to avoid this close(). It won't change the behavior but it might make maintenance/change less error-prone.