fix: Fix long parallel writings

[dmga44]

Versions of the test test_ec_parallel_writing with bigger file sizes
(65M) often fail. The reason behing those failures is the following
sequence of operations:

• some mountpoint starts writing some chunk X (some kilobyte of that
  chunk), this triggers the creation of a chunk for that chunkIndex and
  successfully finishes the write operation sending to the master an
  update in the size of the file.
• other mountpoint (before the other one updates the file size) starts
  writing some chunk Y, such that Y < X, i.e Y has a lower index than X.
  Successfully finishes those writes, and at the moment of the updating
  the file size, sends a size lower than current one by at least the
  chunk X.
• in the master side, the update of the size (fsnodes_setlength
  function) removes the chunks which are not necessary considering the
  current file size, thus remving the chunk X and trashing the previous
  writes on it.
• new writes on the X-th chunk allocate a new chunk and successfully
  finishes the writing process, but the missing data is irreversible.

Solution is to extend the fsnodes_setlength to accept a
eraseFurtherChunks parameter to determine whether or not those chunks
should be erased. Summarizing:

• the client communication of write end
  (SAU_CLTOMA_FUSE_WRITE_CHUNK_END header) will not remove chunks not
  necessary given the size sent.
• the client communication of truncate (SAU_CLTOMA_FUSE_TRUNCATE
  header) and truncate end (SAU_CLTOMA_FUSE_TRUNCATE_END header) will
  continue removing chunks further than the given length.

As a side effect, the LENGTH metadata logs must be changed since the
state of the filesystem can not be recovered without saying whether
further chunks must be deleted or not:

• old metadata will be handled as always removing further chunks.
• new metadata will have 0|1 to represent whether the further chunks
  must be deleted.

A test extending this issue was added in the LongSystemTests suite.

BREAKING CHANGE: changes the changelog format generated by master
server.

An initial tool for downgrading the system from the v5.0.0 to v4.X.X was
uploaded with all the previous changes.

[rolysr]

LGTM. Just a minor doubt

[uristdwarf]

Can you mark the commits as breaking change, e.g:

fix!: Fix long parallel writings

And add at the end a BREAKING CHANGE footer.

See here for an example

https://www.conventionalcommits.org/en/v1.0.0/

[ralcolea]

Great job @dmga44 👍 🔥 🚀