Leaking Two FD and one thread every time Options.refresh() is called

[joshgontijo]

From #148

There are no clean up code for the following so it is leaking a thread and two FD every time it is called.

syncIdleConnectionMonitorThread.start();

asyncConnectionManager = new PoolingNHttpClientConnectionManager(ioreactor);

---

One more thing. The following thread is never started for async.

setOption(Option.ASYNC_MONITOR, new AsyncIdleConnectionMonitorThread(asyncConnectionManager));

---

Hi, I'm also running in this, not with thousands of threads like reported in #140 but at least two. This can be reproduced by simply configuring an custom Object Mapper without invoking any further code
Unirest.setObjectMapper(new MyObjectMapper());
The static block inside Options with the refresh() causes an initial thread creation before setObjectMapper invokes refresh again. The previously created thread will not be removed.

I also think this whole static stuff is a design flaw (see #140) which should be replaced with a more object oriented interface like suggested by #145 and #138.

---

If you only call setProxy() or setTimeout() only once, you won't see this issue as much.

This is definitely a design issue. Since both setProxy() and setTimeout() are static, those settings can affect any running Thread calling Unirest. I believe the correct design would be having a factory method to create a specific Unirest instance per dependency. With the current design, the only way to avoid race condition is to load Unirest with custom classloader per dependency and encapsulate the custom class loader.