Store the JSON response in mongo, not the native objects
For example, trying to store a row with a Timestamp field will generate an error:

https://github.com/huggingface/datasets/issues/4413

> Type is not JSON serializable: Timestamp

See https://stackoverflow.com/questions/50404559/python-error-typeerror-object-of-type-timestamp-is-not-json-serializable

Options to solve it:

1. convert to JSON (using [`orjson_dumps`](https://github.com/huggingface/datasets-server/blob/7444bd367cf391d849b529d31eed4730d2d2b405/libs/libutils/src/libutils/utils.py#L56-L64) as the service `api` is currently doing). It would be the best way: the API would only serve a precomputed JSON, instead of doing the conversion on every request, which is redundant and thus reduce the interest of the cache. The issue is that it requires migrating the database, which requires good preparation.
2. convert to JSON, then convert back to a native dict, before storing into the mongo database. It's really not optimal since the data is converted, then converted back, then stored, then converted again on every request. But it's a lot easier to implement since no migration is required.
3. create a new optional field to the mongo cached splits collection: `json_rows_response`. If present, return it, else: return `rows_response`. We would have to give a flag to the caller to know if the response is already in JSON or not. And the worker that fills the database would now only fill `json_rows_response`. This way, we have more time to migrate the database, and we can do it more easily by first filling the missing `json_rows_response`, then deprecating `rows_response`.
Store the JSON response in mongo, not the native objects: For example, trying to store a row with a Timestamp field will generate an error:

https://github.com/huggingface/datasets/issues/4413

> Type is not JSON serializable: Timestamp

See https://stackoverflow.com/questions/50404559/python-error-typeerror-object-of-type-timestamp-is-not-json-serializable

Options to solve it:

1. convert to JSON (using [`orjson_dumps`](https://github.com/huggingface/datasets-server/blob/7444bd367cf391d849b529d31eed4730d2d2b405/libs/libutils/src/libutils/utils.py#L56-L64) as the service `api` is currently doing). It would be the best way: the API would only serve a precomputed JSON, instead of doing the conversion on every request, which is redundant and thus reduce the interest of the cache. The issue is that it requires migrating the database, which requires good preparation.
2. convert to JSON, then convert back to a native dict, before storing into the mongo database. It's really not optimal since the data is converted, then converted back, then stored, then converted again on every request. But it's a lot easier to implement since no migration is required.
3. create a new optional field to the mongo cached splits collection: `json_rows_response`. If present, return it, else: return `rows_response`. We would have to give a flag to the caller to know if the response is already in JSON or not. And the worker that fills the database would now only fill `json_rows_response`. This way, we have more time to migrate the database, and we can do it more easily by first filling the missing `json_rows_response`, then deprecating `rows_response`.