When application passes invalid read concern sub-options to client, the client forwards those options ultimately to the server, and the server rejects the queries due to invalid read concern sub-options.

From the user experience standpoint, the application developer only finds out that the read concern sub-options were invalid after a query is issued. We could potentially improve developer experience by validating read concern sub-options during client construction, to provide earlier feedback about invalid sub-options.

A consideration here is forward compatibility with server versions that might add additional read concern sub-options or additional values to the existing sub-options like level.

This applies to:

1. Unknown options:

irb(main):008:0> a=Mongo::Client.new([],read_concern:{hai:9})
D, [2019-01-02T14:40:15.958429 #17296] DEBUG -- : MONGODB | EVENT: #<TopologyOpening topology=Unknown[]>
D, [2019-01-02T14:40:15.958610 #17296] DEBUG -- : MONGODB | Topology type 'unknown' initializing.
=> #<Mongo::Client:0x47195355313360 cluster=#<Cluster topology=Unknown[] servers=[]>>
irb(main):009:0> a.options[:read_concern]
=> {"hai"=>9}

In these cases I suggest warning that the option is unknown but keeping it and forwarding it to server and allowing the server to return an error.

2. Options which are not user-settable:

irb(main):008:0> a=Mongo::Client.new([],read_concern:{after_cluster_time:9, afterClusterTime:10})

I suggest raising an exception when these options are encountered.

Note that driver currently warns & discards on (other, not read concern) top level unknown options.