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

[klaudworks]

@arielsepton could you look into why make -j2 test fails but make test works so that we can get this merged? I'm pretty short on time in the next few weeks.

[klaudworks]

I think the remaining error is test flakiness so I'd ask you to run the tests again. In status_test.go you define a map of test cases and iterate over the map to execute the test cases while expecting them to be executed in order.

However, in Golang "the iteration order over maps is not specified and is not guaranteed to be the same from one iteration to the next". - go.dev/ref/spec

Therefore, it is likely that test cases are not always evaluated in the order you intended.

	cases := map[string]struct {
		args args
		want want
	}{
		"Success": {
			...
		},
		"StatusCodeFailed": {
			...
		},
		"RequestFailed": {
			...
		},
		"ResetFailures": {
			...
		},
	}
        
        for name, tc := range cases {
        t.Run(name, func(t *testing.T) {

[arielsepton]

Hey! Thanks so much for the contribution — this is really great!!

Before we merge, would you mind also updating the example to reflect the new functionality? It would also be awesome if you could implement the same support for the DisposableRequest resource.

Let me know if you’re up for that — I’ll make sure to review it quickly!

[klaudworks]

I can update the example but I don't have capacity to implement support for the DisposableRequest at the moment.
Would you be okay with getting it merged while keeping the default Behavior for the disposable request?