gtphub on master

Hi OpenBSC, I have just merged the gtphub branch to master. The request to do that has been standing for a while, to let Jenkins run the tests etc., but there were still quite volatile parts of the code until now. The last few days, I have successfully tested gtphub in a mock network, using a web capable phone, a sysmoBTS running an SGSN on-board, and a gtphub and OpenGGSN on my laptop. It works: I can browse the net! @Andreas: since our last discussion, I have incorporated all of your comments. It *does* make sense after all. A peer may request gtphub from any port, and by sequence number tracking, the response will go back to that port and IP. Requests with unknown sequence number will be routed according to the header's TEI, which means that gtphub will send Requests always to the default port (a proxy with a specific port may be configured, though). Another thanks for your input! GGSN resolution by DNS (GRX C ares) is taking a shortcut: hoping that the peer will try again, after a DNS request has first been fired, gtphub will simply not respond. Once a GGSN has been resolved and sits in the cache, Requests are served immediately. In this way, I avoided a mechanism to queue incoming Requests (until DNS is done, so that other messages are not blocked in the meantime), which would have been the proper way to do this, but would add quite a bit of complexity that is really only needed for the very first resolution of a given GGSN... According to spec, an SGSN will resend Requests a number of times, so this should actually be sufficient, I guess. Some small bits are still outright missing, as you may notice from the various TODO comments. But all the main parts are implemented and tested. Probably a number of bugs still need to be found. Some infrastructural things are also missing. Coming up is the debian build, and soon to follow: rate control. Thanks for any reviews! (I intend to employ proper peer review for gtphub from this point on...) ~Neels