Relations with PreResourceResolver parents are called with wrong parent

[disq]

Describe the bug

If the parent has a PreResourceResolver defined, relations are called with the Resolver's output and not the "new item" from the PreResourceResolver.

This also works fine in mock tests as it should be, which is interesting.

Expected Behavior

Relation Resolver methods should be called with the result from the parent PreResourceResolver item as the parent.

Steps to Reproduce

Sentry issue SOURCE-AWS-A:

interface conversion: interface {} is types.KeyListEntry, not *types.KeyMetadata
goroutine 9995245 [running]:
runtime/debug.Stack()
	/opt/hostedtoolcache/go/1.19.2/x64/src/runtime/debug/stack.go:24 +0x65
github.com/cloudquery/plugin-sdk/plugins.(*SourcePlugin).resolveTableDfs.func1.1()
	/home/runner/go/pkg/mod/github.com/cloudquery/plugin-sdk@v1.4.1/plugins/source_scheduler_dfs.go:77 +0x78
panic({0x776c700, 0xc07debab40})
	/opt/hostedtoolcache/go/1.19.2/x64/src/runtime/panic.go:884 +0x212
github.com/cloudquery/cloudquery/plugins/source/aws/resources/services/kms.fetchKmsKeyGrants({0x8a92270?, 0xc0008927b0?}, {0x89b9340?, 0xc06e902a80?}, 0x89b9340?, 0xc00030f600?)
	/home/runner/work/cloudquery/cloudquery/plugins/source/aws/resources/services/kms/key_grants_fetch.go:14 +0x3b8
github.com/cloudquery/plugin-sdk/plugins.(*SourcePlugin).resolveTableDfs.func1()
	/home/runner/go/pkg/mod/github.com/cloudquery/plugin-sdk@v1.4.1/plugins/source_scheduler_dfs.go:87 +0xbb
created by github.com/cloudquery/plugin-sdk/plugins.(*SourcePlugin).resolveTableDfs
	/home/runner/go/pkg/mod/github.com/cloudquery/plugin-sdk@v1.4.1/plugins/source_scheduler_dfs.go:74 +0x585

Fixing the key_grants_fetch.go to be:

	k := parent.Item.(*types.KeyListEntry)
	config := kms.ListGrantsInput{
		KeyId: k.KeyArn,

Should fix the problem temporarily, but it breaks the mock test in keys_mock_test.go. So the mock tests case works OK somehow.

Possible Solution

No response

Provider and CloudQuery version

4.14.0

Additional Context

No response

[disq]

Looks like this is caused by the if c.IsNotFoundError(err) check (it's just return nil currently) not setting the resource to nil.