Issue 15 + Refactoring

I've made fairly significant changes to the class hierarchy and I'm in doubts whether they are to the better.
Please ignore the status and config part for the time being and let me know if the *Repository changes make sense. Specifically, I tried to extract common subject registration/lookup logic into AbstractSubjectValidatingRepository and succeeded for for InMemory and LocalFileSystem but with Zookeeper I was afraid to significantly alter the flow of the code and finished up using the new base class in a somewhat awkward manner. The tests pass, but I don't feel terribly good - so any comments, whether positive or negative will help :smile: 
Hmm... Sorry to backtrack on this one too, but again, after more consideration, I'm not completely sure this belongs in the Repository interface, rather than in the REST Server... What irks me is that being a String, it is kind of ill-defined by nature, meaning that it's hard to provide any kind of expectation around it. Is "ACTIVE" the only correct state? Is there even just a good and a bad state? Or are there also transitory or standby states (starting up, passive, etc.)?

I think that for the purpose of the health check, we could perhaps have a /status endpoint that just relies on the BaseRepository's isValid() to decide whether to return a 200 or some 500. Then, when we think this through some more, in terms of providing extra details about the actual Repo implementation's state, we can re-introduce this with a more constrained return type that can provide both a general status (active/broken/inactive/whatever) as well as arbitrarily detailed metadata as well.

I imagine the main purpose you had for the health check was automated monitoring for the purpose of alerting systems or load balancers. If that's the case, then I think you would probably be better served with a more constrained return type than with arbitrary Strings.

So again, I would lean towards moving this out of the Repo interface, and into the REST Server/Client only, meaning this interface would not be changed at all, in the end...

Would you be okay with that?