Improve duplicate carb entry protection with backend-layer check and user notification

Is your feature request related to a problem? Please describe.

Issue #175 showed issues where concurrency issues in the application may lead to duplicate carb entries. Consensus when analyzing and (trying to) reproduce(ing) the issue, that it was bound to a loop-in-progress context. A bandaid-type fix was found with PR #248 .

Describe the solution you'd like

During tests of #248, various testers and developers discussed a possible second layer of duplicate protection to be added in CarbStorage. A possible check could be something like

if new entry

has exact same timestamp as existing entry

has exact same amount as an existing entry

has createdBy manual (so entered via app)

Additionally, it would be nice to propagate a successful filtering of duplicates via a notification to the user. This is probably optional and lower priority.

Describe alternatives you've considered

PR #248 adds a UI-specific fix/workaround for this issue until a larger rewrite of data persistence and concurrency can take place.

Additional context

We need to rule out if a backend-filtering like this possibly hinders carb entry backdating. For example, how does this work with the actual timestamp when a user backdates, e.g. is the actual (duplicate) entry something like 2024-06-01T12:13:14.123Z(= needs to be filtered) and a backdated entry is something like 2024-06-01T12:13:14.000Z ? CarbEntry events hold a createdAt and actualDate properties. We need to look at these to make sure we only filter true duplicates.

nightscout / Trio