Add MissingFieldStrategy for KeyInjection

[klaudworks]

Description of your changes

This implements MissingFieldStrategy as discussed in #81.

I have:

• Read and followed Crossplane's [contribution process].
• Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

@arielsepton The existing tests work already. Feel free to already check if the implementation matches what you would expect.
I will now proceed to add / improve the tests to test each of the 3 different strategies for handling missing fields.
Then, I will also test it manually in my local setup.

[klaudworks]

I added changes to tackle #84.

What changed?

I improved the robustness of parsing responses from JSON into an object by replacing the masked secret values first and then parsing the String as a JSON. Beforehand, it wasn't possible to parse any response that had a masked number. It just worked because of another bug as describe in #84.

Unfortunately, this is still not sufficient to fully deal with masking numbers & booleans. During the deletion phase of a request the referenced secret data may already be deleted. This is no problems for replacing values in JSON strings because replacing

{ "secretString": "{{secret:ns:key}}" } with an empty string results in { "secretString": "" } which is valid JSON
but patching a masked number / boolean e.g. { "secretNumber": {{secret:ns:key}} } without quotes results in { "secretNumber": } which is not valid JSON.

To tackle that issue, I went with a simpler solution and explicitly excluded masking numbers and booleans inside response bodies in the first place. Values are just masked if they are JSON strings. This is definitely not the optimal solution. However, it improves upon the previous behavior where a masked number would lead to a bug that stores all response values without masking (#84). Also, I assume masking booleans or numbers is a real use case in the first place but If you think o.w. I already made some improvements in the JSON parsing to enable you to do so. My additions should strictly improve upon the previous behavior.

Tests

• I modified all existing test cases to use the missingFieldStrategy: delete and added a test case each for setEmpty and preserve.
• I tested the preserve strategy successfully with the Stripe request discussed in Prevent secretInjectionConfigs from setting empty value for key that is not present #81. The case where the API only returns a secret value on CREATE but doesn't return it in a follow-up GET request works now.
• e2e test work.

Outlook

If you wanna work on masking numbers / booleans, I recommend to add the masking of those values in again in the secret_patcher.go and to deploy the sample Request. You will notice issues during deletion before the secret values are cleared first and the response can not be parsed into a proper JSON anymore.

[klaudworks]

@arielsepton tagging you here because I turned the PR draft into an actual PR