Implement combining validators

[borzunov]

This PR proposes a way to combine validators. The API should match the following requirements:

1. An application should be able to add new validators to an existing DHT instance, so that several applications (e.g. the averager and the MoE) may use one DHT instance (passed to them in the class constructors).
2. Some validator classes allow using multiple validator instances (e.g. each application may add a SchemaValidator with its own schema), others don't (e.g. only one RSASignatureValidator makes sense).
3. The validator classes should be executed in a specific order (e.g. RSASignatureValidator should remove the signature before SchemaValidator will try to deserialize a record and validate the schema).

The proposed solution is described in this comment.

[justheuristic]

[optional suggestion] the term for adding (with overwriting) keys and values of one dictionary to another is dict1.update(dict2). Perhaps it is more intuitive to rename this method to .update_validator. That said, i definitely do not insist and the decision is entirely yours.

[borzunov]

Initially, I've decided to name it extend to emphasize the different behavior from update (the fact that it does not change the existing keys). However, now it seems to be unclear, so I'll rename it to set_if_not_present.

[justheuristic]

[i have no further suggestions, LGTM]

[borzunov]

I've tried to implement a simpler scheme to combine validators. Now the applications may append them to the DHT in any order:

# In the application A's code
dht.add_validators([RSASignatureValidator(), SchemaValidator(SchemaA)])

# In the application B's code
dht.add_validators([SchemaValidator(SchemaB), RSASignatureValidator()])

Internally, each validator class implements the .priority property and the .merge_with() policy, so the CompositeValidator may merge validators of different classes correctly (e.g. with the OR policy for schemas) and then figure out the correct order for applying validators. See the code for details.

I've also changed the SchemaValidator to reject keys that are not specified in any of the schemas (that became possible due to the OR policy mentioned above).

I will re-request the review because of these significant changes.

[mryab]

Suggested change

	def extend(self, validators: List[RecordValidatorBase]) -> None:
	def extend(self, validators: List[RecordValidatorBase]):

[borzunov]

Why is that?

I thought the convention is that this means no annotation, and to add one we should explicitly specify -> None (like we do in other parts of the project, e.g. here).

[borzunov]

@justheuristic has verbally confirmed that I can merge this.