4653 Use the selected webhook version in the webhook payload

[albertisfu]

No changes were needed for most webhook event type methods to ensure that the selected webhook version in the UI is applied to the webhook payload, except for Opinion Search Alerts, which will be addressed in #4682.

I just added tests to confirm that the correct webhook version is used in the payload and to verify that multiple webhook events can be sent for each enabled event type, as each type may now have two versions.

Additionally, I updated the webhook test dummies to display the appropriate version for each event type under testing.

Finally, I modified the test template to show both the event type and version (previously, it only showed the endpoint URL), making it clear which webhook is being tested.

In summary, the following event types:

• Search Alerts (Oral Arguments and RECAP)
• Old Docket Alerts Report
• Docket Alert
• RECAP Fetch

now support both V1 and V2 of the webhook, even though their payloads are identical in both versions.

Final question: We have a date_created field in the webhook payload. Should we add a value for V1, or do we not yet have a deprecation date for V1?

Fixes: #4653

[mlissner]

We have a date_created field in the webhook payload. Should we add a value for V1, or do we not yet have a deprecation date for V1?

Do you mean date_deprecated? If so, I think the date is when this merges, and if you want to add a week, that's fine too?

[albertisfu]

Do you mean date_deprecated? If so, I think the date is when this merges, and if you want to add a week, that's fine too?

Yes, deprecation_date is set for V1. I’ve added it as a setting called WEBHOOK_V1_DEPRECATION_DATE, which defaults to "2024-11-18." We can adjust it when merging the PR.

The deprecation_date is a datetime object, so the hour, minutes, and seconds default to 00, and it is in UTC format: 2024-11-18T00:00:00+00:00.

For V2 deprecation_date:null

• Added tests related.

[mlissner]

Thank you both; in it goes!