perf: speed up adding fields, reduce memalloc if field name is already prefixed with "app."

[robbkidd]

Which problem is this PR solving?

• Closes perf: "app." + key is allocating new objects still #401

There is a remarkable amount of memory allocation occurring under load to perform the "app." prefixing of field names by the Beeline.

Short description of the changes

This change skips the memory allocations needed for string concat and usage if the "app." prefix is already present on the field name provided.

Benchmarks

Existing behavior is no slower or memory hungry, but for every field name provided by the Beeline user that starts with "app.", that is one less memory allocation of the size of the field name string.

BenchmarkBeelineAddField/oldAddField/whatever
BenchmarkBeelineAddField/oldAddField/whatever-12                19654003                60.52 ns/op            8 B/op          1 allocs/op
BenchmarkBeelineAddField/AddField/no-prefix
BenchmarkBeelineAddField/AddField/no-prefix-12                  18939754                60.65 ns/op            8 B/op          1 allocs/op
BenchmarkBeelineAddField/AddField/half-prefixed
BenchmarkBeelineAddField/AddField/half-prefixed-12              22405790                51.22 ns/op            4 B/op          0 allocs/op
BenchmarkBeelineAddField/AddField/all-prefixed
BenchmarkBeelineAddField/AddField/all-prefixed-12               27381916                42.88 ns/op            0 B/op          0 allocs/op

[kentquirk]

This is a good call, and provides a nice on-ramp to adding the app prefix explicitly.

[MikeGoldsmith]

I think this is the right way to go. The work done in #402 by introducing a cache introduced too much lock contention. This will allow users of the beeline to improve perf. by doing the app. prefix themselves.

The query is not blocking and I don't think it'll have a material impact.