Make working with key-value pairs more convenient

[cthulhu-rider]

Overview

We have several features which are represented as key-value string|binary pairs:

neofs-sdk-go/object/attribute.go

Line 8 in df5c69e

type Attribute object.Attribute

neofs-sdk-go/container/attribute.go

Line 8 in df5c69e

Attribute container.Attribute

neofs-sdk-go/netmap/network_info.go

Line 103 in df5c69e

type NetworkParameter netmap.NetworkParameter

neofs-sdk-go/client/common.go

Line 63 in df5c69e

func (x *prmCommonMeta) WithXHeaders(hs ...string) {

and so on. In order to process them there is a need to use the constant keys. In current implementation they are defined in NeoFS API Go library. I think it is still the best place to define them, but we need to either

1. create aliases in SDK code
2. use NeoFS API Go directly in application code.

While 1 seems redundant, 2 is not recommended approach at all.

On the other hand, values ​​encode certain data, which leads to the need to know what and how to decode when processing the value.

So we need smth more convenient.

Proposal

Provide per-key function pair which

• allows to not use particular key constants
• encapsulates data encoding
• abstracts application from the way how data is encoded in some component (e.g. attribute carriers like object or container)
• saves application from adapting to possible alternative embedding ways (for example, an attribute becomes a field)

A prime example of this approach is a function pair:

neofs-sdk-go/container/attribute.go

Line 114 in df5c69e

func SetNativeNameWithZone(c *Container, name, zone string) {

neofs-sdk-go/container/attribute.go

Line 125 in df5c69e

func GetNativeNameWithZone(c *Container) (name string, zone string) {

These functions allow the application to understand that the container's name and zone can be written to the container descriptor, and abstract away the rest of the details. At the same time, this is not a method of the Container type, which means that the application understands that the function is just an auxiliary one, which means that SDK has all the tools to do the same directly.

I propose to implement function pairs for all such cases. Also it'd be useful to mention these functions in docs of the base methods (SetAttributes for example above).

• note that similar solution is proposed in client: Add dedicated parameters for well-known X-Headers #166