high memory usage when reading ocf file

Nobody has claimed this yet.

Hi, I'm trying to read an ~555mb ocf file to slice and it seems to be getting inflated to ~9gb of ram. Am I doing something wrong or can this be improved somehow?

ocf file size (bytes): 581275587
goavro version: 2.7.2

go tool pprof -top ocf.profile:
```
File: avrotest.test
Type: alloc_space
Time: Apr 24, 2019 at 4:18pm (UTC)
Showing nodes accounting for 10.72GB, 99.83% of 10.73GB total
Dropped 3 nodes (cum <= 0.05GB)
flat flat% sum% cum cum%
7.46GB 69.50% 69.50% 8.91GB 83.01% github.com/kmulvey/avrotest/vendor/github.com/linkedin/goavro.makeRecordCodec.func2
1.10GB 10.26% 79.76% 1.20GB 11.14% testing.(*common).Helper
0.64GB 5.94% 85.70% 0.64GB 5.94% github.com/kmulvey/avrotest/vendor/github.com/linkedin/goavro.Union
0.54GB 5.07% 90.77% 0.54GB 5.07% github.com/kmulvey/avrotest/vendor/github.com/linkedin/goavro.(*OCFReader).Scan
0.26GB 2.38% 93.16% 0.58GB 5.42% github.com/kmulvey/avrotest/vendor/github.com/linkedin/goavro.stringNativeFromBinary
0.25GB 2.32% 95.47% 0.33GB 3.03% github.com/kmulvey/avrotest/vendor/github.com/linkedin/goavro.bytesNativeFromBinary
0.20GB 1.84% 97.31% 0.20GB 1.84% github.com/kmulvey/avrotest/vendor/github.com/linkedin/goavro.longNativeFromBinary
0.09GB 0.88% 98.19% 0.09GB 0.88% testing.callerName
0.09GB 0.87% 99.06% 0.09GB 0.87% github.com/kmulvey/avrotest/vendor/github.com/linkedin/goavro.doubleNativeFromBinary
0.08GB 0.77% 99.83% 10.73GB 100% github.com/kmulvey/avrotest.TestHelloWorld
0 0% 99.83% 8.91GB 83.01% github.com/kmulvey/avrotest/vendor/github.com/linkedin/goavro.(*Codec).NativeFromBinary
0 0% 99.83% 8.91GB 83.01% github.com/kmulvey/avrotest/vendor/github.com/linkedin/goavro.(*OCFReader).Read
0 0% 99.83% 1.36GB 12.66% github.com/kmulvey/avrotest/vendor/github.com/linkedin/goavro.buildCodecForTypeDescribedBySlice.func1
0 0% 99.83% 0.40GB 3.74% github.com/kmulvey/avrotest/vendor/github.com/stretchr/testify/assert.NoError
0 0% 99.83% 0.80GB 7.41% github.com/kmulvey/avrotest/vendor/github.com/stretchr/testify/assert.True
0 0% 99.83% 10.73GB 100% testing.tRunner

```

```
package main

import (
"bufio"
"os"
"testing"

"github.com/linkedin/goavro"
"github.com/stretchr/testify/assert"
)

func TestHelloWorld(t *testing.T) {
var records []map[string]interface{}
ocfFH, err := os.Open("/opt/code/data/20180531.avro")
assert.NoError(t, err)
defer ocfFH.Close()

br := bufio.NewReader(ocfFH)
ocfr, err := goavro.NewOCFReader(br)
assert.NoError(t, err)

for ocfr.Scan() {
rec, err := ocfr.Read()
assert.NoError(t, err)

var r, ok = rec.(map[string]interface{})
assert.True(t, ok)

records = append(records, r)
}
assert.NoError(t, ocfr.Err())
assert.Equal(t, 2175228, len(records))
}

```

Start with the TestHelloWorld reproduction in the issue and inspect goavro's OCFReader.Scan and Read paths, especially the makeRecordCodec allocation shown by pprof. Re-run the reproduction and profiling to determine whether decoding or retaining all records drives the growth. Done means the memory behavior is explained and any improvement is verified against this workload.

Written by the indexing model from the issue text.