Truncate msg length in trace

[menghanl]

fixes #695

[knz]

This truncation is incorrect if the string contains UTF-8 multibyte characters. It can produce invalid UTF-8 sequences.

[dfawley]

This is true, but is that a problem?

[irfansharif]

If we have a large slice and then only hold on to a reference pointing to just the first x elements of the slice (slice[:x]), Go still holds onto the large slice (/backing array) in memory. (The same is true for strings). The following snippet for example doesn't allocate/copy per iteration, s is pinned in memory throughout:

func main() {
    s := "abcdefghi"
    a := make([]string, 100)
    for i := 0; ; i++ {
        a[i%100] = s[:3]
    }
}

Presumably what we want here is an explicit copy instead.

[menghanl]

@irfansharif I added a commit to make a copy of the substring. PTAL.

[irfansharif]

yup, that works.

[dfawley]

For huge amounts of data and msgs that are natively Stringers, it's probably best to call truncate(stringerMsg.String(), truncateSize) inside fmt.Sprintf() to avoid an allocation and copy of the data that will be removed anyway. But this is probably a pretty trivial savings.

[menghanl]

The change in this PR doesn't work because it makes trace.LazyLog not lazy any more.

After this change, with trace on, even if /debug/requests page is never rendered, each request and response will be serialized when LazyLog is called. This adds large unnecessary overhead to each RPC.

Closing this PR because of that.