CXX-1748 add read_concern support to find_options

[EdanStasiuk]

Related Ticket: CXX-1748

Summary

This PR introduces support for setting read_concern on mongocxx::options::find and v1::find_options. Previously, unlike write_concern and read_preference, read_concern could not be set per operation. This change aligns the API with the existing behavior for write concerns and read preferences. Additional PRs will follow to extend this support to other relevant option classes.

Core Implementation

• Added read_concern setter/getter to v1::find_options.
• Updated v_noabi::find to propagate read_concern from find_options.
• Added accessors for read_concern in internal find_options implementation.
• Updated append_to in v1/collection.cpp and v_noabi/mongocxx/collection.cpp to insert readConcern into the BSON options document, ensuring the field is correctly propagated to MongoDB.

Tests

• Added unit tests for read_concern in:
  • v1/find_options.cpp
  • v_noabi/options/find.cpp
  • v_noabi/collection_mocked.cpp
• Tests validate that read_concern can be set, retrieved, and passed through mocked collections correctly.

[EdanStasiuk]

I'm opening this PR as a draft, as it's my first contribution to this repo. The goal is to add support for setting read_concern on individual operations, such as mongocxx::options::find, update, and similar operations, just like write_concern and read_preference. I plan to extend this functionality across all relevant operations so that read_concern can be used consistently at the per-operation level. Feedback on the approach and implementation is welcome before finalizing the PR.

[eramongodb]

Hello, @EdanStasiuk! Thank you very much for this initial draft PR. The proposed changes are a very good start to addressing CXX-1748.

I plan to extend this functionality across all relevant operations so that read_concern can be used consistently at the per-operation level.

As noted in CXX-1748, recommend limiting the addition of readConcern to option classes which already provide at least one of either writeConcern or readPreference. Quoting the referenced spec which has since been relocated to here:

Since all operations defined in this specification are performed on a collection, it's uncommon that two different read operations on the same collection would use a different read concern, potentially causing mismatched and out-of-sync data. As such, the most natural place to indicate read concern is on the client, the database, or the collection itself and not the operations within it.

However, it might be that a driver needs to expose read concern to a user per operation for various reasons. As noted before, it is permitted to specify this, along with other driver-specific options, in some alternative way.

If you intend to address all relevant option classes in a single PR, feel free to mark this PR as "Ready for Review" once they have all been implemented. If you intend to address each option class individually in separate PRs, feel free to mark this PR as "Ready for Review" once the relevant code for find options class is fully implemented.

[eramongodb]

Hello, @EdanStasiuk. Are you still working on this PR?

[EdanStasiuk]

@eramongodb yes, I am. Sorry for the delay, I’ve been meaning to come back to this but got caught up with midterms and coursework this semester. I’ll work on addressing the feedback sometime this week.

At a glance though, I'll limit the addition of read_concern to option classes that already expose either writeConcern or readPreference, for consistency as discussed in CXX-1748.

I plan to finish the implementation for find_options in this PR and can open additional PRs for the remaining option classes once this one is complete.