Mismatch between GUI and API for stored data

[manuelstein]

Current behaviour:

1. when creating a datalayer KV in the GUI and editing the value, the current value shown is a special character
2. Edit a datalayer value (e.g. "foo") through the GUI by entering a string (e.g. "bar") and saving it, write a function that simply does print(context.get("foo")), the output in the log is the base64 encoded version of the data (i.e. "YmFy")
3. The first key (was named "KKK") vanished from the GUI, although it is still readable from a function context.get("KKK")

Expected behaviour:

1. The GUI should show an empty form, not a special character that triggers the editor validation to complain (red box with X marking the line)
2. The content read in the function should be the same content edited in the GUI, e.g. saving "bar" to a key "foo" should cause print(context.get("foo")) to output "bar"
3. A user-chosen keyname like "KKK" should not vanish from the Object Store pane in the GUI; if it's a reserved key, the user should be warned; in this case, I think I think it might be an indexing problem, i.e. listKeys start=1 should actually request start=0

[iakkus]

Thanks for catching these!

1. The special character was an extra '\0' byte that was added to the DataLayerService/RiakAccess for putting data with an empty value. Riak itself doesn't support empty values, so the extra byte was created. Now the get operation in RiakAccess removes that extra byte before returning. The reason is that the GUI could create a storage object without any content.

2. This was due to the GUI not checking whether the uploaded value was in binary format. Now, it makes a distinction between the two and only uploads binary content in base64 format. As a result, the function code gets whatever is in the data layer. Note that the put() operation accepts a string for the value parameter, so it is the user code's responsibility to ensure that that's the case.

3. The start index has been fixed.

Will commit in a minute.