Fix some thread safety and exception-related problems

[A248]

1. Regarding EconomyProvider, the previous behavior returned the Set early, before the computations inside the loop necessarily complete. Also, the Set was unsynchronized despite usage in a multithreaded context. Thirdly, Subscriber#succeed was called regardless of failure; now, #succeed is not called if an exception occurs.
2. Using ExecutorService#submit implies the caller will analyze the returned Future for exceptions. While your usages are not intended to throw exceptions, future code refactoring and extreme cases can turn debugging missed exceptions into a hellish experience. Using #execute ensures exceptions will at the least be logged.
3. To keep EventBus thread-safe, EventTypeTracker ought likewise to be thread-safe. Thus the friends map should be concurrent and atomics performed on it atomic. Additionally, I've simplified the code in the process and removed an unnecessary collect-and-stream operation.

I apologize for not strictly following the contribution process: I became carried away and simply completed all this, before reading the guidelines. However, I think you will find that "people say it sounds good."

[lokka30]

Thank you very much for the pull request A2, I will be sure to review it as soon as I get some free time. :)

[Geolykt]

Incredibly tiny nitpick (doesn't really have an effect as at that point it is all single-threaded) I'd prefer using ConcurrentHashMap#newKeySet() over using a standard synchronized HashSet as you cannot modify them while iterating over synchronized Set.

Or use an unmodifiable set, which might be the better option considering that I do not think that it should be modified at that point onwards

[A248]

Replying to @Geolykt :

Since mutability of the returned Set is not guaranteed by the method contract, I don't think clients should be assuming mutability -- and surely it seems too much to assume mutability within the context of iteration, which is generally a rare property of Collection implementations.

However, I like your idea of using an unmodifiable set. A documentation PR clarifying the status of the returned Set would be useful here: i.e., have the javadocs specify the collection yielded may or may not be mutable. Furthermore, these are default methods; the provider's implementation can change, and so may ours (see #180).