The initial implementation had a couple of flaws, including:
* Generally overcounting the free space by ATE_SIZE bytes per sector.
* Counting multiple ATEs of the same ID if placed in the same sector.
The correct behavior is to only count the most recent entry.
* When a sector was mostly or completely filled with small data sizes,
there was a correction term applied in the wrong location.
* The same correction term would be mistakenly applied when a sector
was filled with only delete ATEs, which resulted in undercounting
the free space in that sector.
This is addressed by rewriting the API according to a simple principle:
the total free space in a filesystem should equal the sum of free space
in every GC'd sector (minus 1 sector reserved for GC itself).
This should work because during garbage collection, ATEs are not moved
between sectors arbitrarily. Only one sector gets GC'd at a time and
every entry in sector N gets either removed or copied to sector N-1.
This means that any two valid entries that occupy a single sector would
still occupy a (different) single sector before and after the operation.
This property lets us simplify the total free space calculation by
considering one sector at a time and reapplying the calculation which
was just introduced for `zms_active_sector_free_space()`.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
a39b2779ee