build: upgrade to golangci-lint v1.39.0

[fjl]

This updates the lint tool and fixes the issues reported by the new tool version.

WARN [runner/nolint] Found unknown linters in //nolint directives: composites 
eth/catalyst/api_test.go:71:13: composites: `github.com/ethereum/go-ethereum/params.ChainConfig` composite literal uses unkeyed fields (govet)
	config := &params.ChainConfig{big.NewInt(1337), big.NewInt(0), nil, false, big.NewInt(0), common.Hash{}, big.NewInt(0), big.NewInt(0), big.NewInt(0), big.NewInt(0), big.NewInt(0), big.NewInt(0), big.NewInt(0), big.NewInt(0), nil, nil, big.NewInt(0), new(params.EthashConfig), nil}
	           ^
consensus/ethash/ethash.go:116:12: unsafeptr: possible misuse of reflect.SliceHeader (govet)
	header := *(*reflect.SliceHeader)(unsafe.Pointer(&mem))
	          ^
consensus/ethash/ethash.go:120:42: unsafeptr: possible misuse of reflect.SliceHeader (govet)
	return mem, *(*[]uint32)(unsafe.Pointer(&header)), nil
	                                        ^

[karalabe]

The other similar conversions seem a bit different. Perhaps lets do this part the same way?

	var cache []byte
	cacheHdr := (*reflect.SliceHeader)(unsafe.Pointer(&cache))
	dstHdr := (*reflect.SliceHeader)(unsafe.Pointer(&dest))
	cacheHdr.Data = dstHdr.Data
	cacheHdr.Len = dstHdr.Len * 4
	cacheHdr.Cap = dstHdr.Cap * 4

[fjl]

I think there is no real difference between what you posted and what's in the diff.
In the []uint32 to []byte conversion in algorithm.go, it accesses the length of the
slice header instead of calling len. But they give the same result, and I prefer using len.

[karalabe]

I guess the difference is that the alternative uses dstHdr to retrieve the Len and Cap (no idea where these come from), vs you assume these will have certain values based on mem. I'm almost certain your code is fine since we never append to these constructed slices, but unsure what would hapen if we did.