refactored writing to (dimension) variables

[blazk]

@dvalters writing to variables is more complex than it seemed to me at first!

• In general I think DATA_REPR may be modified by a sequence of multiple write() and truncate() calls followed by a single release() call. Note that a single write() or truncate() call may in principle result in a text that cannot be translated back to data - we should be translating text representation back to data only when we release(), not at each write()/truncate(). I think supporting this may need changes in our architecture.
• Current implementation assumes that editing is done with a single write(2) call. This assumption seems to be working if I edit DATA_REPR with Vim.
• invalid edits are ignored (log.warning()) is printed)

[dvalters]

Hi @blazk - yes I did not expect it to be as complicated either! - Thanks for this PR - looks good. I will merge it now. Does look like we would need to make some changes to the overall architecture for more flexible variable editing. (given the range of potential tools people could edit the files with...)

[blazk]

Thanks @dvalters

So in terms of architecture, currently it is stateless meaning an entire operation (e.g. creating a variable, changing variable data array) must be done within a single FUSE call.

This doesn't always work:

• we need some way of storing the state between FUSE calls (to store partial text edits before release() is called)

• we need to delay creating a variable until we know all the bits (e.g. you cannot create a variable when you create a directory because you don't know what should be dimensions of this new variable; you need to wait until user creates DIMENSIONS file)

So I think we need e.g. a Variable class to store a state between FUSE calls