Fix - Uses fetch_add() to accumulate usage counters in LoadedPrograms

[Lichtso]

Problem

The pattern load(), saturating_add_assign(), store() on an atomic counter is a race condition because it does not use the transactional properties of atomics. Also DelayVisibility tombstones currently don't have their usage counter incremented on use.

Summary of Changes

While fetch_add() gives up the saturating arithmetic, this is first of all an extremely improbable edge case as even with the wildest TPS numbers currently envisioned a single validator would still have to run for tens of thousands of years without a single reboot and all transactions only using a single program, for this 64 bit counter to ever overflow. And even if it does, the atomics do wrapping and do not panic, so it is self correcting.

[codecov]

Codecov Report

Merging #34319 (a147952) into master (d451675) will increase coverage by 0.0%.
Report is 1 commits behind head on master.
The diff coverage is 100.0%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #34319   +/-   ##
=======================================
  Coverage    81.9%    81.9%           
=======================================
  Files         819      819           
  Lines      220228   220225    -3     
=======================================
+ Hits       180535   180559   +24     
+ Misses      39693    39666   -27     

[mergify]

Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis.