Check all setting controls available and support them in ansible role.

Compatibility table has not been updated due to lack of clarity what to fill into max NeoFS Node compatible version. I believe this column should be removed. The current table is wrong: testnet has been successfully updated with the old role, while table says max version is 36.

For the latest locode DB version we need to change default archive name to locode_db, i.e. use _ instead of . in file name.

Now we are overwriting the binaries with versions that the playbook can reach. In the images we ship, we need to make sure that the version we are testing matches the version in the image, for this we need to add a flag that will disable the download and install binaries step

1. Allow configuring TLS for internal RPC.
2. Switch from morph.endpoint.client to morph.endpoints.
3. Ensure no binary keys are used anywhere.
4. Update compatibility table.
5. Release a new version with a nice changelog.

Role version -> supported node versions.

https://github.com/nspcc-dev/neofs-node/releases/tag/v0.37.0

In local consensus mode morph.validators in IR's config can be omitted now, morph.consensus.committee will be used instead.For detached consensus, it is a required config parameter now.

Should / could this section be removed?

Suppose I want to use this nice role to manage my node, what should I do to make it work? What are the options? What I can and can not do? All of this should be documented in the README.

The role should fetch the latest version of the node and install it by default.

There are two directiroies in /etc/neofs/:

• /etc/neofs/ir
• /etc/neofs/ir_az or another letter

We need to leave one directory and clean up others.

0.36.0 release has added a consensus section to morph config: https://github.com/nspcc-dev/neofs-node/blob/v0.36.0/config/example/ir.yaml#L22

It needs to be supported. Options are very much similar to those NeoGo has.

https://github.com/nspcc-dev/neofs-node/pull/2345/files#diff-fa2020290a9f23e3eb4637b37d9e842b320c3cbab60b19ce31aae3bfa3dc4d2d

Looks like after #65 we always have neofs_ir__validators using the same set of nodes for the node and CN. It's not always correct, we can have some set used for CNs (and this will never change for a network) and then some newer set used in the node config (related to nspcc-dev/neofs-node#2394). I'd suggest using two different variables here.

Why do I think so?

1. It will be easier for me (a dev) to debug some deploys (look configs, see (understand) what version is running (if I see config_key: config_val, I do know what is happening if I do not see it, I try to recall every config value I have in my code and see what default it has and how it (its missing I mean) can affect the code)).
2. Defaults can change. Fixed explicit value can not change.
3. Same config template is easier to analyze (e.g. one deploy works, another does not, how do they differ?). Also, it is a common situation when an admin comes to a dev and asks about a config, so a dev should be able to see the difference easily.
4. If a value is not needed at all, let's drop it and not just skip it cause "it works well without it".
5. Understanding config is better than ignoring config. If an admin does not understand a certain parameter, it will be better (IMO) for him to figure its value (meaning) out, not drop it. It should help in the future.

@AnnaShaleva, @roman-khimov, @smallhive, @cthulhu-rider (devs who gonna see configs).

P.S. are default values so bad that they deserve an additional removal commit (time, attention, etc)?

check should be done after handler

https://github.com/nspcc-dev/ansible-neofs-ir/blob/master/tasks/healthcheck.yml