[X] Implement proper operation handles that allow users to wait for specific events
[ ] Clean up the read operation for clients
[ ] Check that the corner case where read and writes go over the length of the file work correctly
[ ] Return the number of bytes read or written in the ToastyFS_Result struct
[ ] Make parallel uploads/downloads configurable
[ ] Recalculate next write locations whenever a write occurs, not at each read
[ ] avoid replay attacks
[ ] add logging (when chunk servers connect and disconnect to the metadata server)
[ ] Should list scenarios that need testing, like those where chunks would be dropped
[ ] Update DESIGN.txt and the code to remove the chunk list message. The information of chunks held by chunk servers is now transmitted to the metadata server during state updates
[ ] clean up the replication factor business
[ ] Implement metadata server WAL
[ ] Add failt injections to the simulation
[ ] Add authentication
[ ] Add release build and allow switching between debug, release, coverage, sanitizer builds while calling make
[ ] When an operation is committed to the WAL, it may then fail due to not deterministic reasons (out of memory). When the metadata server restarts and replays the log, the operation may succede and cause the system to diverge from the last instance of the process. Is this not a problem? How do we solve it?
[ ] Add notes on who inspired the testing approach
[ ] Add notes on benchmarks and that we don't do batching
[ ] Fix endianess when writing to network and the WAL
[ ] Add a change counter to FileTree. The counter is initialized to 0 and updated any time the tree is changed. When a new file is created, the current change counter is assigned to it. This makes it possible to verify that the file didn't change in between read and write operations without that clumsy previous hash list and previous chunk size.