field: speed up Element.Bytes

[AlexanderYastrebov]

Write bytes in 64-bit chunks made from adjacent limbs.

goos: linux
goarch: amd64
pkg: filippo.io/edwards25519/field
cpu: Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz
        │   HEAD~1    │                HEAD                 │
        │   sec/op    │   sec/op     vs base                │
Bytes-8   60.31n ± 1%   13.67n ± 2%  -77.34% (p=0.000 n=10)

        │   HEAD~1   │              HEAD              │
        │    B/op    │    B/op     vs base            │
Bytes-8   0.000 ± 0%   0.000 ± 0%  ~ (p=1.000 n=10) ¹
¹ all samples are equal

        │   HEAD~1   │              HEAD              │
        │ allocs/op  │ allocs/op   vs base            │
Bytes-8   0.000 ± 0%   0.000 ± 0%  ~ (p=1.000 n=10) ¹
¹ all samples are equal

[AlexanderYastrebov]

I've observed Element.Bytes could be improved while profiling https://github.com/AlexanderYastrebov/wireguard-vanity-key:

Limbs are not available to the user (unlike e.g. Point.ExtendedCoordinates) so I could not fix it in my code without forking or vendoring this lib.
This change also makes Element.Bytes loop-less just like all other Element methods that use limbs directly.

[FiloSottile]

Nice! I appreciate the diagram.

Since these are non-trivial changes to the parts of the library that track upstream, would you consider mailing them as Go CLs? If not, have you signed the Google CLA and are ok with me submitting them on your behalf after we merge them here, to keep upstream in sync?

[AlexanderYastrebov]

would you consider mailing them as Go CLs?

Sure, I've created golang/go#71603 for this change.

If not, have you signed the Google CLA and are ok with me submitting them on your behalf after we merge them here, to keep upstream in sync?

Yes, I've contributed to stdlib before so this is also ok.

[AlexanderYastrebov]

golang/go#71603 was landed, how do we proceed with this one?

[FiloSottile]

Merged, thank you!