Fix flaky e2e test

[PavelJankoski]

Summary

Fix flaky e2e test

Changes

• If the device is present for some application for some reason, we were getting 409 error. With this workaround we are not failing the test if a request gets 409.

Testing

Steps

Check CI if it turns green on every PR.

Results

The CI should turn green

Checklist

• Scope: The referenced issue is addressed, there are no unrelated changes.
• Compatibility: The changes are backwards compatible with existing API, storage, configuration and CLI, according to the compatibility commitments in README.md for the chosen target branch.
• Documentation: Relevant documentation is added or updated.
• Testing: The steps/process to test this feature are clearly explained including testing for regressions.
• Infrastructure: If infrastructural changes (e.g., new RPC, configuration) are needed, a separate issue is created in the infrastructural repositories.
• Changelog: Significant features, behavior changes, deprecations and fixes are added to CHANGELOG.md.
• Commits: Commit messages follow guidelines in CONTRIBUTING.md, there are no fixup commits left.

[ryaplots]

I am not sure this is the best solution, cause if we get 409 in this request for some other reason we won't know. @mjamescompton what do you think?

[mjamescompton]

Yeah if we don't fail on the 409, that would mean the device is not created correctly but we are hoping the tests don't require it to so it will pass.

What in the backend is causing the 409?

[PavelJankoski]

@ryaplots @mjamescompton It happens to return 409 Conflict when the device is already created (for some reason not deleted from some cluster with other tests, or when tests run in parallel i suppose) but in our case that doesn't matter. The only thing that matters in this test is that the device is present in the db.
Other solution is to create devices with random id's every time the test runs (with adding timestamp in the id for example)