Ensure StorageID in metabase is used correctly

[carpawell]

Is your feature request related to a problem? Please describe.

I'm always frustrated when we use "dynamic" code. In the storage engine currently, we can accept any (non-empty) storage ID and think that it corresponds to the peapod (or blobovniczas tree earlier). In fact, we now store 1/2 IDs that are left by blobovnizcas (it was a migration mistake or some garbage) and nobody knows it.

Describe the solution you'd like

If a storage ID is unknown, do WARN or ERROR logs. All the storages can be checked additionally. Such a situation is completely erroneous, a metabase must be in sync with a blobstor, no unexpected IDs should be found.

neofs-node/pkg/local_object_storage/blobstor/get.go

Lines 29 to 32 in e6eeda1

	if len(prm.StorageID) == 0 {
	return b.storage[len(b.storage)-1].Storage.Get(prm)
	}
	return b.storage[0].Storage.Get(prm)

Describe alternatives you've considered

(:

Additional context

I have found blobovnicza tree's IDs in mainnet when looked at #2844.

[carpawell]

BTW, storage indexes hardcoding is also awful to me ([0] is for FSTree, and [1] is for peapod and just believe me).

[cthulhu-rider]

@carpawell SDK is not the best place for this issue 🤔

[carpawell]

Woops

[roman-khimov]

Do we need storage ID at all?

[carpawell]

Do we need storage ID at all?

This is how we understand what storage to check (a "small" one (peapod currently) or a "big" one).