BIND 10 #168: separate ASIO from Boost and remove custom code

[BIND 10 Development]

#168: separate ASIO from Boost and remove custom code
----------------------+-----------------------------------------------------
 Reporter:  larissas  |        Owner:  each                                       
     Type:  task      |       Status:  reviewing                                  
 Priority:  major     |    Milestone:  04. 2nd Incremental Release: Early Adopters
Component:  b10-auth  |   Resolution:                                             
 Keywords:            |    Sensitive:  0                                          
----------------------+-----------------------------------------------------
Changes (by jelte):

  * owner:  jelte => each


Comment:

 This doesn't seem exactly right, the hasQueuedMessages&&checkCommand was
 used in before select() loops where the processing of the loop could have
 had synchronous request/response communication. If there are other
 messages arriving while this is being done these are queued and need to be
 resolved at some point. In the loop structure the right place for this is
 at the start of the loop. In an asynchronous setup, I'm not entirely sure
 whether this should be handled at all, though I haven't fully wrapped my
 head around asio yet (do we get an immediate calling of the io_services
 handler the moment a new message arrives, even if we're still busy
 handling other stuff? Or does asio call it as soon as we're done, at which
 point we do have possibly queued messages, and if so the current way is
 probably right, although we could consider putting it in moduleccsession
 itself, at the end of checkcommand (while stuff_left handle_stuff)).

 There is, however, a more immediate problem; in the current trunk,
 commands aren't handled at all. Since ModuleCCSession is started without
 an io_service, it defaults to the (non-asio) SocketSession, which expects
 manual polls. I have a small patch that fixes this, but it needs expansion
 of the asio_link API, to get access to the underlying io_service object.
 This isn't really clean and I think we should probably refactor this,
 though I'm not sure how, and i'd like to have a bit of a brainstorm for
 this (and probably another ticket).

-- 
Ticket URL: <http://bind10.isc.org/ticket/168#comment:22>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development