feat: add support for configurable readConcern in MongoDB connection

[vahiwe]

Previously, Medici defaulted to the MongoDB driver's readConcern with no option to override it. This caused critical issues in replica set environments using readConcern=majority, including negative balances and missing credits due to stale reads.

This change introduces a way to configure the readConcern level, allowing users to set values like local or majority based on their consistency and availability needs.

Fixes #119

[koresar]

Brilliant! Lovely changes.
We need to explain that important feature in the docs too.
Could you please add the corresponding README.md somewhere? Feel free to find the most appropriate place yourself.

[Uzlopak]

LGTM

Do we need some kind of test?

Now also countDocuments gets readPrefence passed. Could this result in some breaking change? Because IOptions had already readPreference before.

Should we release a major?

[vahiwe]

@koresar The changes have been added to the README as requested. Please let me know if you’d like the section moved elsewhere or if any further clarification is needed.

[vahiwe]

@Uzlopak I tried replicating the issue in a dev environment, but it was a bit tricky since the traffic patterns and the number of interactions with the ledger are very different compared to production, where we have thousands of customer transactions. So far, I haven’t seen any adverse effects, but it's hard to simulate the same edge cases.

Do you have any pointers on the best way to test this more thoroughly?

[vahiwe]

Regarding the countDocuments now receiving readPreference, I don't expect this to be a breaking change, but I'm happy to double-check or adjust if there are any concerns about compatibility with existing usage.

[Uzlopak]

I used mongodb few years ago, so my skills are little bit rusty.

We should not start to test basic mongodb behavior.

My gut feeling says, that it should be not an issue.

But I personally would recommend to just cut a major release to avoid any potential issue. Of course the devs using this package are still responsible to validate the code and determine if the code is working correct or not. But who knows, what performance tricks and what not are used by them and suddenly some "sneaky" change like this is implemented.

[vahiwe]

Makes sense, @Uzlopak.

I'm not sure what the release process for the package looks like, so I’m not certain how to ensure this goes out as a major release.

[Uzlopak]

This is just "loud thinking" so that koresar can consider this when cutting the next version. ;)

[koresar]

Hello all.
This is not a SemVer MAJOR IMO.
Doing the release now.

[koresar]

Published as v7.2.0