Remove hard-coded IRC and eepsite tunnels

[EinMByte]

I propose removing the hard-coded tunnels. The tunnels can still be in the default tunnels.cfg file.

For end-users, the only practical consequence would be that you can't set the options for these tunnels from the command line.

[anonimal]

I agree with the 1st half, but this should also be kept in mind during removal:

2016-02-02 19:50:56     &anonimal       I agree with #107, but this brings up something I forgot I wanted to bring up a while ago:
2016-02-02 19:51:27     &anonimal       I'd like to be able to run Nth amount of kovris on one machine.
2016-02-02 19:51:46     &anonimal       This is something we could easily do where java i2p cannot easily do (AFAICT).
2016-02-02 19:52:03     +EinMByte       anonimal: That requires getting rid of the singleton design
2016-02-02 19:52:16     +EinMByte       Which starts with what I'm doing right now
2016-02-02 19:52:19     &anonimal       Good, I don't think *anyone* here liked the idea to begin with.
2016-02-02 19:52:47     +EinMByte       BUT, it would already be possible to run multiple ClientContext objects over a single router when I'm done
2016-02-02 19:53:06     &anonimal       So, with the "Nth Kovri" design of CLI/Config handling, I think we should take a certain independence into account.
2016-02-02 19:53:23     &anonimal       Hmm.
2016-02-02 19:53:44     +EinMByte       Ideally I'd like to see something like Router myRouter(some args);
2016-02-02 19:54:01     +EinMByte       and then do stuff with that object, possible have multiple such objects
2016-02-02 19:54:05     &anonimal       So Nth routers, different ports each, etc.
2016-02-02 19:54:09     +EinMByte       s/possible/possibly

@EinMByte In short, I think we should still consider end-user usability in addition to proposed API. I know this creates more hurdles since core won't know what its in client, but I wonder if we can keep our present CLI aesthetics (we can throw out how it maps) while continuing our new design work. Either way, sounds exciting 😄

This ticket also relates to #34 and #96.

[EinMByte]

I'm going to go ahead and do this.

[anonimal]

Cross-posting JFTR:

2016-02-03 11:17:24     +EinMByte       I'm about to do #107, since anonimal seemed to agree
2016-02-03 11:17:55     +EinMByte       I'll make sure the tunnels still exist in tunnels.cfg
2016-02-03 11:18:05     +EinMByte       just not in kovri.conf
2016-02-03 11:22:42     +EinMByte       By the way, client/core is split up 
2016-02-03 11:22:47     +EinMByte       We still need to provide an easy "Api.h" or something, because now you'd have to include a lot of files
2016-02-03 11:22:47     +EinMByte       It would be nice if one header file would be enough
2016-02-03 11:28:36     +EinMByte       I'll probably write a "tutorial" on how to bundle i2pd when that's done
2016-02-03 11:29:05     +EinMByte       (in the hope that it will be useful for monero developers)
2016-02-03 12:57:38     &anonimal       EinMByte: I only partially agreed, please read again. A complete killing of CLI for tunnels is not a solution, IMHO, unless it replaced with a better option at it kills usability for the Nth router problem.
2016-02-03 12:58:28     &anonimal       I think we can put our heads together to find an agreeable solution, or maybe you already have better ideas and haven't responded in the ticket.
2016-02-03 12:58:53     +EinMByte       anonimal: Well I removed the options in my fork.
2016-02-03 12:59:38     +EinMByte       I'm not sure if people actually build tunnels from the CLI
2016-02-03 13:00:54     &anonimal       EinMByte: Re: cli tunnels, how do you propose we handle the Nth router problem without having numerous config files everywhere?
2016-02-03 13:02:30     +EinMByte       not sure how that's related to CLI tunnels. The configuration file is an application thing
2016-02-03 13:03:05     +EinMByte       (as are CLI tunnels)
2016-02-03 13:03:13     +EinMByte       Nth router is a core thing
2016-02-03 13:03:30     +EinMByte       Maybe kovri-main won't support multirouter
2016-02-03 13:04:15     +EinMByte       If it does, we need an overhaul of the whole configuration and CLI thing
2016-02-03 13:05:32     &anonimal       That's my point. Flexibility could be a hallmark feature of kovri vs. other implementations.
2016-02-03 13:05:38     +EinMByte       Since, as you've said, each router needs its own configuration
2016-02-03 13:05:58     +EinMByte       (or you could run multiple routers with the same config?)
2016-02-03 13:05:59     &anonimal       And doing overhaul now could be better in the long run, IMHO.
2016-02-03 13:06:29      *      anonimal thinks
2016-02-03 13:07:21     &anonimal       Re: all w/same config: if they all point to the same ~/.kovri then I don't think that would work (netdb, etc.)
2016-02-03 13:07:59     +EinMByte       Well, for netdb you need a different folter for each router of course
2016-02-03 13:08:04     +EinMByte       *folder
2016-02-03 13:09:07     +EinMByte       Otherwise you'll always get major problems
2016-02-03 13:10:04     &anonimal       Keeping track of which router gets which netdb sounds weird.
2016-02-03 13:10:21      *      anonimal thinking
2016-02-03 13:10:29      *      anonimal and doing other things ATM
2016-02-03 13:10:57     +EinMByte       anonimal: Well, you just pass a different data directory
2016-02-03 13:23:03     &anonimal       EinMByte: Re: data dir, ok, but not my ideal solution. As long as we keep things moving, sounds good enough for now.