server: Fixed possible file inconsistency when a replica becomes the primary for a file.

When a replica is about to become primary, it updates its local file version to the latest state first. Therefore, it fetches the latest version of each object during the phase called "Replica Reset".

Each object is versioned by a version number retrieved from the file's version counter. The version number gets incremented with every write operation, truncate operation or primary change. Consequently, the latest written object has the highest version number, also called "maxObjVer" in the code.

Before this commit, the future primary sent each backup replica its "maxObjVer". Those replied only with missing objects which had a version higher than "maxObjVer" and only those objects were fetched by the future primary. This approach is wrong since the "maxObjVer" does not tell if the future primary actually saw *all* writes up to that version. Consequently, the future primary may not have fetched all missing objects and could respond with an older version of an object upon a read() request.

This commit fixes the problem by sending a maxObjVer of 0 to each backup replica. Consequently, each backup replica will always respond to the primary with all their object versions and all missing objects are fetched in the subsequent step. Future optimizations are possible to correctly reduce the extent of the exchanged object list and not part of this commit.

git-svn-id: https://xtreemfs.googlecode.com/svn/trunk@3223 f8528748-c2c0-11dd-ba5c-d3b7c2b3b534