Consent serving may not send proper `served_notice_history_id` on slow connections

[Allison King]

Bug Description

If a user is on a slow connection, there is a chance that we won't properly report their served notices. The flow is:

1. When the modal pops up, send a PATCH that notices were served, and receive served_notice_history_ids back
2. When the user saves, send along those served_notice_history_ids

This doesn't work well if step 1️⃣ is slow to respond. step 2️⃣ will fire off with empty served_notice_history_ids.

This is a bug that Cypress has been warning about but which we've been dismissing as a flaky test :)

https://github.com/ethyca/fides/blob/main/clients/privacy-center/cypress/e2e/consent-banner.cy.ts#L1532

Steps to Reproduce

1. Start your cypress runner
2. Throttle your cypress connection by going to the Network tab and selecting "slow 3g"
3. Run only this test: https://github.com/ethyca/fides/blob/main/clients/privacy-center/cypress/e2e/consent-banner.cy.ts#L1532
4. It will likely fail because the patchNoticesServed request doesn't come back quickly enough to provide the history IDs, before we make the patch preference request

Expected behavior

I'm not quite sure how we want to address this—perhaps we need to block the save request until the patchNoticesServed request comes back. This is a little difficult to do with how we've set things up since we use a hook useConsentServed which operates based off of JS events rather than the main event loop.

Screenshots

If applicable, add screenshots to help explain your problem.

Environment

• Version:
• OS:
• Python Version:
• Docker Version:

Additional context

Add any other context about the problem here.

[Rachel Silver]

Moved to here: https://ethyca.atlassian.net/browse/PROD-1265
We'll talk in retro today about bug tracking but I don't want this to go missed in planning.