Check LOCODE derived node attributes

[alexvanin]

If the node provides some attributes, they must be valid or not conflicting. If there is LOCODE attribute, it must be valid. If there are other geographical attributes that can be derived from LOCODE, they must be logically valid and be set in the same format. If those conditions are not met, the node must be denied entering the network.

For now there can be two ways:

1. Don't allow any LOCODE derivable attributes without LOCODE attribute set
2. If LOCODE is not set, check derivable attributes for correctness

The second one seems to be a more solid choice.

Originally posted by @realloc in #397 (comment)

[alexvanin]

Inner ring node must have sanity checks of attributes, for sure. However check of LOCODE derived attributes might be a bit too much. There are many corner cases: some omitted attributes from LOCODE base, comparing strings with and without dyacritics, etc.

Probably the best way to solve LOCODE sanity check is to forbid all LOCODE derived attributes in bootstrap txs.

Proposal for sanity check algorithm for LOCODE:

1. If derived locode attributes are present -- ignore this bootstrap tx.
2. If LOCODE attribute is present -- add derived attributes from db.
3. End.