Append-friendlier serial tiles serializer

[yhahn]

Context

The serialtiles serializer is written like a pretty reasonable newline delimited stream writer with the one exception that in the final _flush case it decides to not write a trailing newline. This causes all kinds of headaches for anyone attempting to resume or append to a previously written serialtiles files.

What happens now (newlines visualized for ease). Note that the last line does not have a trailing \n.

JSONBREAKFASTTIME\n
{ ... }\n
{ ... }\n
{ ... }

Now let's append to this stream assuming we can write in a way consistent with the previous writes...

# appended version
JSONBREAKFASTTIME\n
{ ... }\n
{ ... }\n
{ ... }{ ... }
{ ... }\n
{ ... }\n
...

Not great.

So then appenders do some trickery...

No big deal, appenders can just write lines with a prefixed newline! \n{ ... }

# appended version
JSONBREAKFASTTIME\n
{ ... }\n
{ ... }\n
{ ... }
\n{ ... }
\n{ ... }
\n{ ... }

Great! But what if our append starts after the initial header is written or while another initial stream is writing rather than after the first stream has concluded?

# appended version
JSONBREAKFASTTIME\n
\n{ ... }
\n{ ... }
\n{ ... }

Oww, now we end up with an empty line (the empty string sandwiched between \n\n). 🍔

---

Proposed solution

• Always write a trailing newline. No weird exception on flush.
• Add no-op handling for an empty string in deserialize. This is for the empty string sandwiched between \n\n for anyone who's been trying to append and has hit this corner case.
• This branch also adds error handling for bad data passed for serialization (refs tilelive.serialize() should throw on invalid Tile obj #117).

This is a breaking change though some testing indicates previous versions of tilelive handle a single trailing \n on serialtiles files fine.

For safety will bump major.

cc @rclark @mapbox/core-tech