Expose UpdateMarkerFile func with transactional lock

[michalpristas]

Complementary function to work introduced in #8254

Allows read-modify-write withing single transational lock

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[pchila]

I think we are missing a testcase.
This change is also opening the possibility for caller of (load|save)MarkerToPath to read/write the update marker in an unsafe way with the isSafe parameters.

[michalpristas]

@pchila i resolved everything because i redid how this is executed

[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 feat/upgrade_marker upstream/feat/upgrade_marker
git merge upstream/main
git push upstream feat/upgrade_marker

[elastic-sonarqube]

Quality Gate passed

Issues
3 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
61.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 7cf55e8

History

• 💚 Build #22363 succeeded 7263633
• 💔 Build #22299 failed 54be077
• 💛 Build #22272 was flaky 32dce55
• 💔 Build #22205 failed 6f1c8f1
• 💔 Build #22204 failed 267d3b5

cc @michalpristas

[pkoutsovasilis]

The code changes LGTM, @pchila please do have a look 🙂

[pchila]

I would put this on hold until we have a clearer idea if we want to maintain locking for the upgrade marker file.
Should we decide to change the solution to a lock-free implementation this should not be merged and #8254 should be reverted