Drop compatibility code from loadPlacementBuilder.BuildPlacement

[roman-khimov]

Expected Behavior

Placements are provided by SDK.

Current Behavior

We had to replicate the old behavior in loadPlacementBuilder.BuildPlacement when updating to RC8 (#2346).

Possible Solution

We will be updating to RC10 and when that happens we'll have new sorting everywhere. So we can drop this code at the same time and either don't use placement there at all or generate some OID for it as needed.

Refs. nspcc-dev/neofs-sdk-go#438 and #2442.

[cthulhu-rider]

i see two ways:

1. calc fake oid.ID with load_announcement_<epoch>0000... with fixed-len epoch
2. sort nodes by public keys lexicographically

[carpawell]

2. you mean the same "main" node for the same container set every epoch?

[cthulhu-rider]

2. you mean the same "main" node for the same container set every epoch?

yes, why not (taking into account many containers with different leaders). We can also rotate leader by epoch, but this doesn't make much difference

[carpawell]

If we need to have it fine with RC10 I would go that way (the same node subset choose a different node for a different container).

Also, I am totally ok with a separate func in SDK (does not apply any pivot at all, only the epoch).

yes, why not

Not good for a decentralized network IMO. Predefined node does all the money work.

[cthulhu-rider]

Not good for a decentralized network IMO

if u focus on decentralization, then each node will act for itself and send own values directly to the contract instead of other untrusted node (rotation changes nothing in terms of decentralization)

in total, storage nodes' anarchy is not good for economic model, imo we should do some sort of audit actively from the Inner Ring

but this is about other issue, i proposed technically working alternatives

[roman-khimov]

each node will act for itself and send own values directly to the contract instead of other untrusted node (rotation changes nothing in terms of decentralization)

That's the way it should be. But long-term. Short-term we need to rotate leaders in some predictable manner.

[roman-khimov]

Fixed in #2478 without a reference?

[carpawell]

Fixed in #2478 without a reference?

Yes.