Provide different test packages (funcs) for test types generation

[carpawell]

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

I'm always frustrated when I have to debug problems that are related to the randomness of a type I get from test packages. I want to test my code and be sure I get some real values, not calculating the probability of how real a value I get is and if it suits me.

Describe the solution you'd like

A single package (or a separate function) for real random test values, and a single package (or a separate func in the same package) for values that are correct, predictable, and can be used safely in the test code.

Describe alternatives you've considered

No. SDK test packages are (and will be more if we do not change them) unusable in almost all unit tests if they generate random things.

Additional context

nspcc-dev/neofs-node#2917 existed and took some time only because of the random checksum.
Also, I do know that #610 was not fully agreed and there are some thoughts that it should not be this way.

[carpawell]

In fact, I do not know where a real random type can be used. Mb in a fuzzing test.

[roman-khimov]

Tests must be predictable. Randomness is rarely required there.

[cthulhu-rider]

for values that are correct, predictable, and can be used safely in the test code

its impossible to cover all test-specific and context-dependent cases, _correct_ness is too relative. If tested code works with particular data, test code must specify it explicitly. If a test is not robust to randomization, it should just not use it

tests will be more clear if they create instances themselves, rather than pulling them from a closed box. With the exception of rare but existing tests that work with any data

[carpawell]

neofs-sdk-go/object/test/generate.go

Lines 49 to 53 in 3d4a462

	x.SetPayload([]byte{1, 2, 3})
	owner := usertest.ID()
	x.SetOwnerID(&owner)
	x.SetContainerID(cidtest.ID())
	x.SetType(object.TypeTombstone)

This just pissed me off again: a tombstone object with 1, 2, 3 payload, an incorrect object for sure. I do not understand why I have to fix it in my test code.