Disabled connectors cause erasure requests to error

[adamsachs]

Bug Description

When running an erasure request that traverses through a dataset associated with a disabled connector, that erasure request will appear in an errored state (even if it does successfully process erasures for non-disabled connectors).

The underlying error is a KeyError that's being thrown because there is no cache entry for access results for the disabled connector's dataset, and the erasure execution is expecting there to be a cache entry, even if an empty one.

Steps to Reproduce

1. get an environment up with nox -s test_env
2. disable one or both of the Postgresql and MongoDB connectors that are configured by default
3. try running a sample erasure request. you can use a fake email identity, e.g.:

curl --location --request POST 'http://0.0.0.0:8080/api/v1/privacy-request' \
--header 'Content-Type: application/json' \
--data-raw '[
    {
        "identity": {"email": "[email protected]"},
        "policy_key": "default_erasure_policy"
    }
]'

4. navigate and log in to the admin UI and approve the request that's been queued. you should see it quickly move to an ERROR state

Expected behavior

• The privacy request should not error, but should go to a COMPLETE state, even if it's not erasing any data

Environment

test_env, or any other fides environment really

Additional context

In some testing with @Roger-Ethyca and @RobertKeyser, we'd noticed some strange behavior where it seemed like a disabled saas connector was throwing an error depending on what the MASKING_STRICT config property was set to. i've been unable to reproduce that specific symptom locally and i can't see any way in which the MASKING_STRICT property will actually matter in cases where a connector is disabled.

In doing that investigation, though, I noticed the issue here. It's possible that this is actually what we'd been seeing in our testing and we just weren't keeping track of the symptoms closely enough, but i'm not sure about that.