test: fix list fields detection in TestCRDFieldPresenceInUnstructured

[jingyih]

Unblocks #3632

Fixed the incorrect detection of list fields in TestCRDFieldPresenceInUnstructured.

e.g.

=== FAIL: tests/apichecks TestCRDFieldPresenceInUnstructured (6.00s)
    utils.go:149: FAIL: unexpected diff in testdata/exceptions/missingfields.txt:   (
          	"""
          	... // 2370 identical lines
          	[missing_field] crd=logginglogsinks.logging.cnrm.cloud.google.com version=v1beta1: field ".spec.exclusions[].filter" is not set in unstructured objects
          	[missing_field] crd=logginglogsinks.logging.cnrm.cloud.google.com version=v1beta1: field ".spec.exclusions[].name" is not set in unstructured objects
        + 	[missing_field] crd=managedkafkaclusters.managedkafka.cnrm.cloud.google.com version=v1beta1: field ".spec.gcpConfig.accessConfig.networkConfigs[].subnetworkRef" is not set; neither 'external' nor 'name' are set
          	[missing_field] crd=memcacheinstances.memcache.cnrm.cloud.google.com version=v1beta1: field ".spec.maintenancePolicy.createTime" is not set in unstructured objects
exit status 1
          	[missing_field] crd=memcacheinstances.memcache.cnrm.cloud.google.com version=v1beta1: field ".spec.maintenancePolicy.description" is not set in unstructured objects
          	... // 1517 identical lines
          	"""
          )

[jingyih]

/assign @acpana

[jingyih]

Fixes #3571

[jingyih]

/cc @jasonvigil

[acpana]

thank you loads for taking this on 💯

I spotted checked some of the newly fixed exceptions and can confirm that all fixes in #3636 are present here too!

good job! 🥇

[acpana]

I think we may be "double checking" field paths here in the case where a remaining path is not actually present anywhere else. We check it here in the small loop and then again in the outer loop.

But if that's the case we can live with that for now 💯 .

[jasonvigil]

/lgtm
thank you @jingyih

[jasonvigil]

/assign yuwenma

[yuwenma]

/lgtm

[jasonvigil]

This PR isn't merging for some reason. I am guessing perhaps because @acpana used the github method of approving the PR, rather than the oss-prow commands. I will try to approve also, to see if that un-sticks it.

[jasonvigil]

Hmm, doesn't seem to have worked. Looks like it was fine before, we just need approval from @yuwenma

[cheftako]

/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: acpana, cheftako, jasonvigil

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [cheftako]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment