x-pack/filebeat/input/entityanalytics/provider/azuread: avoid work on unwanted datasets

[efd6]

Proposed commit message

During full sync the provider may have state from a previous dataset. So in the case that the user has changed dataset from users to devices or vice versa the provider may publish already existing state in the entity graph. This change adds conditional checks to ensure that unwanted dataset records are not published.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Author's Checklist

• [ ]

How to test this PR locally

Related issues

Use cases

Screenshots

Logs

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-10-06T23:28:39.325+0000

• Duration: 75 min 38 sec

Test stats 🧪

Test	Results
Failed	0
Passed	3209
Skipped	174
Total	3383

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[efd6]

@taylor-swanson I think we can omit these conditions here since the returned values form doFetch should be empty in the case that. Do you agree?

[taylor-swanson]

Yeah it would seem they are redundant in this particular case. I'm trying to think if there is some other edge case, but can't think of anything. doFetch will return empty an empty set if the dataset is disabled, so we really only need to guard the full sync case.

[taylor-swanson]

LGTM

See other comment, but I'm good with removing the wantUsers/wantDevices guards in the incremental update case.

[taylor-swanson]

Yeah it would seem they are redundant in this particular case. I'm trying to think if there is some other edge case, but can't think of anything. doFetch will return empty an empty set if the dataset is disabled, so we really only need to guard the full sync case.

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b azure_avoid_unwanted_work upstream/azure_avoid_unwanted_work
git merge upstream/main
git push upstream azure_avoid_unwanted_work