json-server-refactoring

************************************************************************************
Mohit: Some ideas, please work on these further:

There are many reasons to refactor, but one is that we want to have a worker thread(s) to whom we can dispatch work from the http server thread, so that one request doesn't block the whole http server like now. So let's start from the top:

Instead of the long list of evhttp_set_cb() calls we do now in Json::init(), we should probably set just one: evhttp_set_gencb(httpd, JsonServer::dispatcher, NULL);

Then, in JsonServer::dispatcher we dispatch the request as soon as possible to a separate worker thread. The JsonServer class of course will also maintain a list of free threads, and create new ones if it runs out (and you could get such threads from a method like JsonServer::workerPool).

The worker threads could then be JsonServerWorker objects. They will contain the code to do GET, POST/PUT, DELETE, etc... the bulk of current code.

Now inside JsonServerWorker we can further refactor along the plans you've laid out below. I've identified following ideas:
* The start of all of the process_...() functions currently are much the same: get variables from uri query string, parse the json query object into a json_in object, some error checking, missing / default values, etc. Let's put all of this code into a function that is called from everywhere.
* json_in, json_out and maybe something else should be members of the class, rather than static vars inside the methods.
* this means they need to be reset at the end of each request, since the worker is reused for many requests.
* I haven't thought about it in detail, but maybe there is then some commonalities in the code that creates SQL and executes it. Or maybe not, after all the SQL is different for all of them. Maybe there is at least some - especially when we add authentication it will be the same for all request types.
* The code that sends the HTTP response can probably be common -> yet another method.

After this we get to the ideas listed below, like capsulating operations on the json_in and json_out objects into try/catch blocks.

************************************************************************************

Refactoring includes:
* Handle exception-
  Use try ... Catch to handle exceptions more efficently.
  Recent Exception "Segmentation fault" while using curl http://localhost:8086/json
  While It does not occur using Web Interface. have to figure out reason and handle this case.

* When a POST does not include an _id value, we should return the result of last_insert_id() (the auto_increment key that was assigned to the row) to the client. This could be a new field in the json document that is returned.

* Make existing code more modular and object oreinted-
   Implement "sqlexector" class file.
      -sqlexecutor => This class is use to execute different sql commands used in json_server
          error_state: data member is used to store the current state of sql. It is "true" , if error occur else false.
       -sqlexecutor(): constructor is used to setup session object.
      -executeSql(): function is used to execute the sql command.

* Currently we return content-type text/html which is wrong.
 We should also be more correct with http response code:http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
* Treat "Put" & "Post" request same.

* Allowing to set default schema and table name as drizzled options.
* Tests for 0.2 features.
* Documentation of 0.2 features.