Remove Labelset

[jmacd]

This addresses #590.

Introduces a static helper function metric.Labels(...core.KeyValue) []core.KeyValue which simplifies rewriting of e.g., Bind(meter.Labels(keys...)) to Bind(metric.Labels(keys...)...). The diff is pretty readable. The only significant changes are in sdk.go where the code is reorganized to avoid a new allocation. Whereas before the labels object was managed as a pointer, one that had to be allocated inside Labels(), labels is now a struct embedded in either type of instrument, and the internal makeLabels() function allocates a temporary record that will become garbage if the lookup succeeds and will become the new record otherwise.

It does not change the RecordBatch API as suggested in OTEP 90 (and I'm not sure that it really matters, after some consideration). This PR does change a lot of benchmarks, but the benchmarks weren't measuring the labelset creation so it's apples and oranges.

We have argued that the cost of label set construction can be amortized using bound handles, which is true. Note that there is not a way to amortize this across collection intervals for Observer instruments, because there is no "bound" form of observer instrument and now no LabelSet to perform that function. This is acceptable; perhaps if there is a dire need we can add bound Observers somehow in the future.

The new RecordBatch benchmark is a good summary of the performance change, BEFORE:

BenchmarkBatchRecord8Labels_1Instrument-8     	 1336000	       889 ns/op	     480 B/op	       2 allocs/op
BenchmarkBatchRecord_8Labels_2Instruments-8   	  786096	      1568 ns/op	     480 B/op	       2 allocs/op
BenchmarkBatchRecord_8Labels_4Instruments-8   	  390052	      2818 ns/op	     480 B/op	       2 allocs/op
BenchmarkBatchRecord_8Labels_8Instruments-8   	  228703	      4937 ns/op	     480 B/op	       2 allocs/op

AFTER:

BenchmarkBatchRecord8Labels_1Instrument-8     	 1250874	       942 ns/op	     512 B/op	       2 allocs/op
BenchmarkBatchRecord_8Labels_2Instruments-8   	  651992	      1626 ns/op	     512 B/op	       2 allocs/op
BenchmarkBatchRecord_8Labels_4Instruments-8   	  396933	      2797 ns/op	     512 B/op	       2 allocs/op
BenchmarkBatchRecord_8Labels_8Instruments-8   	  213150	      5165 ns/op	     512 B/op	       2 allocs/op

[jmacd]

The test failures are related to 32bit builds. Investigating..

[jmacd]

Unfortunately this is a real stress_test failure in GOARCH=386. I've studied this and it points to a troubling conclusion somehow related to a dormant problem with #468. I can't find a change in behavior in the SDK itself, and the problem is easily repeatable on GOARCH=386. The problem has not been reproduced for a 64-bit build, and cannot be reproduced before this PR. I suspect this could relate to 64-bit atomic operations being especially slow on a 32-bit platform. I do not believe this is a case of the (infamous) https://golang.org/issue/599.

[jmacd]

Now the test failure looks unrelated.

    batch_span_processor_test.go:163: parallel span generation: number of exported span: got 205, want 200

[krnowak]

Rambled a bit about the record reuse. But the PR looks good!

[MrAlias]

Looks good. Nothing blocking.