Multiple -m parameters saturate threads on mesos slave

[gianluca-sabena]

If start marathon-lb with all marathon masters (multiple "-m" argument):

• messos sandbox log reports multiple errors
• after some hours (eg 8) marathon stop working because marathon-lb use all threads available on mesos slave

Everything works as expected with only one -m master

I suggest to:

• allow marathon-lb to parse multiple -m option so it is possible to pass all marathon nodes
• periodically get elected marathon leader from marathon api
• get apps configuration from elected leader

Cluster: CentOS 7.2 - Mesos 0.27.1 - Marathon 0.15.3 - last mesos-lb docker from docker hub

[brndnmtthws]

Makes sense, since it looks like I'm not actually stopping the event processor thread. I'll follow up shortly with a PR.