Currently, IDL commands are not aware of the generic fields that can be appended to any command. Nor are there response types aware of the data that can be appended to any response. See https://github.com/10gen/mongo/blob/master/src/mongo/idl/generic_argument.idl. We need to allow users of the new RemoteCommandRunnerAPI to add these fields to requests and introspect their values in responses.

Two possible solutions are

(1) (easy) add an extra BSONObj argument to the API's entry point. The BSONObj argument would contain all of the generic fields. It can be appended to the actual command object before it is sent over the wire by simply passing it to the IDL Command's toBSON function, which was built for this purpose. Additionally add an extra field to the response type with generic field values. 

(2) (hard) Enrich the representation of generic args in IDL from list to something like struct. Extend the IDL command and reply types to have a chained-struct like relationship with such a structure, so the generic args/responses can be set and get from the IDL types automatically.

Update following six-week-review - we're going to pursue a middle-ground between the above two solutions. We're going to add a new C++ structure that acts as a container for all of the generic arguments (excluding dbName), that offers the functionality of serializing the arguments to the BSON/BSONObj builder of a command correctly. The new API will take this as argument for a command invocation. Additionally, we will return a parallel c++ structure holding generic response data in the API's command response type. 

In the long run, we should remove the need for this by incorporating generic field setting and getting into the IDL for commands and replies, but an initial spike proved this to be a non-trivial change that we should pursue in the future. For now, let's add the new generic response/reply structures and incoporate them into the API.