Ensure sane filestore behaviour for edge cases

[panhania]

This change was prompted by a comment on another PR.

So, why shouldn't filestore part store operation idempotent? I consider storing the same part again a special case of overlapping parts which was already an error case. We could theoretically allow overlapping parts as long as they are consistent with each other but that significantly complicates the implementation and probably introduces a thousand different edge cases that I prefer not to deal with. We don't need idempotence because GRR flows are single-threaded and Fleetspeak guarantees message delivery so if the same part is sent twice it is a bug in the flow implementation and should be fixed server-side.

This PR also disallows empty parts to be written. The reason here is to keep the behaviour consistent again: if we allocate an empty part at the given offset, it is not possible to store any non-overlapping part at this offset anymore. One could argue that an empty part is never overlapping with anything and from purely theoretical standpoint I agree with that. We could just drop empty parts.

But then again: why would a server ever send an empty part? That sounds like a wasted roundtrip and I think it is better to fail hard to notify the server that something is most likely not right.

[panhania]

Regarding a comment about storing again for a complete file: I added a test case (dfa53cc). It only covers a scenario where we complete the file again but not store a new part for an already complete file. I think I prefer to leave the latter unspecified. It would be nice to return an error in such case but given it requires an extra filesystem check, the code already is like 90% error handling, there is already an error for completing and the scenarios is extremely unlikely anyway, I don't think it is worth polluting the code even more.