Additional PIR opt out confirmation pixels

[THISISDINOSAUR]

Task/Issue URL: https://app.asana.com/0/0/1207733131726022/f
Tech Design URL:
CC:

Description:
I've linked to the implementation task above, but more useful is the proposal task here: https://app.asana.com/0/0/1207999607996551/f
Adds new pixels that indicate how long it takes us to confirm successful opt outs

This involves adding new fields to the DB, so the migration also needs to be tested

Also moves monitoring pixel firing up the stack to the agent manager where IMO it belongs, so special attention needs to be made that nothing is broken there.

Steps to test this PR:

1. With DBP already setup, confirm via the DB view that OptOutJobs have the new fields (createdDate, submittedSuccessfullyDate, sevenDaysConfirmationPixelFired, fourteenDaysConfirmationPixelFired, twentyOneDaysConfirmationPixelFired). Only submittedSuccessfullyDate should be nil.
2. From a fresh start, set up DBP and confirm via the DB viewer again that everything looks correct
3. Let DBP run for a bit (you could change some background activity values to speed it up) and check that opt out created dates are set correctly and that confirmed opt outs get the correct submittedSuccessfullyDate.
4. You probably don't want to wait 7/14/21 days to test the actual pixel firing, so in DataBrokerProtectionStatsPixels, change one of these to just be true "let hasEnoughTimePassedToFirePixel = submittedSuccessfullyDate.hasBeenExceededByNumberOfDays(14)" (e.g. to "let hasEnoughTimePassedToFirePixel = true")

Definition of Done:

• Does this PR satisfy our Definition of Done?

---

Internal references:

Pull Request Review Checklist
Software Engineering Expectations
Technical Design Template
Pull Request Documentation

[github-actions]

	Warnings
⚠️	PR has more than 500 lines of code changing. Consider splitting into smaller PRs if possible.

Generated by 🚫 dangerJS against 8e349b5

[aataraxiaa]

Nice one @THISISDINOSAUR. Changes look great, made one suggestion. Tested and DB is migrated and pixel fired after changing code locally. 👍🏼

[aataraxiaa]

👏🏼

[aataraxiaa]

Nice documentation 👍🏼

[aataraxiaa]

I made an attempt locally at reducing duplication here, but due to the slight differences at numerous points, it was not much of an improvement, so I think fine as is.

[THISISDINOSAUR]

Yeah this duplication bothers me but I couldn't find an alternative that I was happier with

[aataraxiaa]

Maybe we could reduce duplication here with a helper method:

func updateOptOutField<T>(_ fieldUpdate: @escaping (inout OptOutDB, T) -> Void,
                              value: T,
                              forBrokerId brokerId: Int64,
                              profileQueryId: Int64,
                              extractedProfileId: Int64) throws {
        try db.write { db in
            if var optOut = try OptOutDB.fetchOne(db, key: [
                OptOutDB.Columns.brokerId.name: brokerId,
                OptOutDB.Columns.profileQueryId.name: profileQueryId,
                OptOutDB.Columns.extractedProfileId.name: extractedProfileId]) {
                fieldUpdate(&optOut, value)
                try optOut.update(db)
            } else {
                throw DataBrokerProtectionDatabaseErrors.elementNotFound
            }
        }
    }
    ```
    
    Which could then use like:
    
    ```
    func updateSubmittedSuccessfullyDate(_ date: Date?,
                                         forBrokerId brokerId: Int64,
                                         profileQueryId: Int64,
                                         extractedProfileId: Int64) throws {
        try updateOptOutField({ $0.submittedSuccessfullyDate = $1 }, value: date, forBrokerId: brokerId, profileQueryId: profileQueryId, extractedProfileId: extractedProfileId)
    }
    ```
    
    

[THISISDINOSAUR]

I'm torn on this since it's a departure from what's there already, but I certainly have existing gripes with what's there already. My problem I think is I don't have a clear direction in mind for this class

If I make this change I think I want to change some more changes that depart from the rest of the class, at least change the function names to clearly mention optOuts. I think currently I'm leaning towards making those changes

[THISISDINOSAUR]

Okay changed my mind on the names, if I change these names I think I should change all of them, and at that point I a) don't think I should do it now, but b) think it should be a separate PR.
So I'm gonna go ahead and just reduce the duplication, but will do for the existing opt out fields too

Thanks a lot for providing the snippet!

[aataraxiaa]

Nice one @THISISDINOSAUR. Agree on reasoning re: name changes. LGTM!