ames: account for variable-size num fragments

[yosoyubik]

Currently we assume that the number of fragments in a meow has a fixed size of 4 bytes (which is also how we deserialize meows in in lull.hoon; see +sift-meow), but in some cases we will retrieve from the cache a meow that has less than 4 bytes, which means that we will go over the actual length of the meow when calculating the size of the response to be sent.

(To reproduce the problem, this pdf will cause the publisher to crash on the last fragment if anybody requests it using remote scry)

This PR fixes this by checking how many bytes are actually used in a word, and then using that information to correctly calculate the size of the meow.

Thanks to @pkova and @joemfb for helping with this.

[belisarius222]

When would siz_s be zero for a fragment in a non-empty response message?

[yosoyubik]

I think siz_s won't be 0 for a non-empty response. What I think happens is that we have a fragment that is a bunch of 0s, but we still sign it. This makes the number of fragment in the meow take less that the expected 4 bytes but if we still increase the counter by 4, when we calculate siz_s here mew_u->siz_s = len_w - cur_w; (cur_w > len_w) which will make siz_s huge, which will in turn crash here:

  //  write response fragment data
  //
  memcpy(buf_y + cur_w, mew_u->dat_y, mew_u->siz_s);

[pkova]

Consider the following scenario.

We are making a fine request where the response contains 65535 fragments. Almost all of the fragments look like this:

We are specifically concerned with the end of the UDP packet here. The last two fields are the total number of fragments and the actual fragment data. The total number of fragments is normally four bytes long, however...

The problematic scenario occurs when the fragment happens to contain all zeroes. We represent zero fragments by having the data field be completely empty, but this means that the previous field will now be variable width, like this!

The UDP packet just ends after two bytes! This is questionable design to say the least. This is the scenario that this PR addresses.

[joemfb]

this will do