Add endpoints for retrieval of network (node) configuration

[evias]

With multiple catapult networks available, it may be useful to be able to retrieve network configuration from network nodes through catapult-rest endpoints.

The config-network.properties file contains several settings that are needed in client integrations.

Important for Multi-Network Compatibility:

• blockGenerationTargetTime = 15s: Used for date displays and date estimations.
• namespaceGracePeriodDuration = 2m: Used for notifications about namespace expiration
• currencyMosaicId = ..: Used to identify the currency mosaic on the network
• harvestMosaicId = ..: Used to identify the harvest mosaic on the network
• epochAdjustment = ..: Used to adjust timestamp of nemesis block

Important for Fee estimations:

• minFeeMultiplier = 100: Used for fee estimations. (node specific)
• rootNamespaceRentalFeePerBlock = 1'000'000: Used for fee estimations.
• childNamespaceRentalFee = 100'000'000: Used for fee estimations.
• mosaicRentalFee = 500'000'000: Used for fee estimations.

Important for User Experience:

• maxRollbackBlocks = 40: Useful for transaction persistence.
• maxTransactionsPerAggregate = 1'000: Useful for form validation.
• maxCosignaturesPerAggregate = 15: Useful for form validation.
• lockedFundsPerAggregate = 10'000'000: Useful for feature compatibility.
• maxHashLockDuration = 2d: Useful for notifications or general UX.
• maxSecretLockDuration = 30d: Useful for notifications or general UX.
• minProofSize = 1: Useful for form validation.
• maxProofSize = 1000: Useful for form validation.
• maxMosaicDuration = 3650d: Useful for form validation.
• maxMosaicDivisibility = 6: Useful for form validation.
• minNamespaceDuration = 1m: Useful for form validation.
• maxNamespaceDuration = 365d: Useful for form validation.
• reservedRootNamespaceNames = xem, nem, user, account, org, com, biz, net, edu, mil, gov, info: Useful for form validation.
• maxAccountRestrictionValues = 512: Useful for notifications or general UX.
• maxMosaicRestrictionValues = 20: Useful for notifications or general UX.
• maxMessageSize = 1024: Useful for form validation.
• maxNameSize = 64: Useful for form validation.
• maxChildNamespaces = 500: Useful for notifications or general UX.
• maxNamespaceDepth = 3: Useful for form validation.
• maxMultisigDepth = 3: Useful for form validation.
• maxCosignersPerAccount = 10: Useful for notifications of general UX.
• maxCosignedAccountsPerAccount = 5: Useful for form validation.

If some of those fields seem to be less important to retrieve (mostly "form validation"), they do allow much smoother multi-network capabilities for out client integrations (wallets / explorers / cli / sdk).

[Vektrat]

no problem adding this, @dgarcia360 feel free to suggest endpoint name/structure before we come up with our non-ideal one ^^

[Vektrat]

i forgot to mention this should be provided by the core node somehow

@Jaguar0625 @gimer @BloodyRookie

[dgarcia360]

The problem with this endpoint is that the node could lie, there is no way to verify that the configuration returned is the one being used.

[Vektrat]

The problem with this endpoint is that the node could lie, there is no way to verify that the configuration returned is the one being used.

i don't think this is an issue here, i believe in this environment "lying" is a network worry, when you are specifically querying a node for its (individual) configuration, i suppose you are already assuming it may be lying, in fact, if you use this endpoint it probably means you trust this node for some reason already - but keep discussing

[dgarcia360]

I see 👍 , the same happens to other existing endpoints such as "/node/info". We can add a warning in the docs remarking that for a given set of endpoints, it is better to trust them only if using your node.

@Vektrat Let's continue discussing if you can retrieve these properties directly from catapult-api, or if this should be provided to you somehow to unblock the issue.

[dgarcia360]

Endpoint suggestion: symbol/symbol-openapi#54

[Vektrat]

it has been decided that this will be implemented as follows:

• the REST config will allow to reference a path where the catapult-server config file can be found
• it is up to ops to decide when and how this is managed (the file is copied/fetched at deploy time to a specific REST location, etc) - this means, that file will be detached, and if the original is changed, there is a possibility of forgetfulness to sync the REST copy, it is up to @dgarcia360 to consider if this is relevant enough to point out at the docs, probably not
• the whole config file will be dumped, without worrying about sensible data (there isn't any) - this is the case now, but i might add a list of fields to be added just in case anything sensible is added in the future, and i will be most likely filtering it with the endpoint suggestion by david