Update prefix tree instead of rebuilding from scratch on config changes

[pixitha]

Is your feature request related to a problem? Please describe.
When adding or updating the config for a single subnet, rebuilding the tree on a large config can take a long time. (there are issues with the post timeout as well).

Describe the solution you'd like
It would be nice if we could update the part of the tree that needs updates instead of rebuilding the entire tree. This applies to additions and changes to the config, but also the logic surrounding v4 and v6. If we make a change to the v4 subnets, don't rebuild the v6 tree and visa versa.

Describe alternatives you've considered
We discussed maybe building multiple trees, but that appears to cause too many other issues with processing the updates across multiple trees, and would probably end up causing a fair amount of more resources.

Additional context
A single /24 addition to the config can take 15+ minutes to actually properly update the tree, based on the large scale of overall prefixes.

[vkotronis]

Proposed solution to develop (note to self):

1. In-memory prefix tree holds rule hashes
2. We keep track of what is added and removed (rule/prefix/asn)
3. We update only the part of the tree that is affected

So the configuration microservice needs to keep track of the different prefixes, asns and rules using hashes and send to the prefix tree diffs only. I will discuss with the team the complexity involved in this very useful optimization and will get back regarding the target release (ARTEMIS enterprise with the current planning).