Improve add_facts performance

[seanmil]

When making multiple add_facts calls to add facts to an already present and large set of target facts performance declines as more are added due to the initialization and copying of the large hashes each time.

This change merges the added facts in place to the existing facts, which slightly improves performance.

[donoghuc]

seems like a good improvement. Can you update commit message to be formatted with https://github.com/puppetlabs/bolt/blob/main/CONTRIBUTING.md#pull-requests style that will help our docs automation?

I'll need to dig in to the failing tests, it appears to be unrelated to this work.

[seanmil]

I will fix this up and re-push, but just so you know - the original symptom of VERY slow add_facts calls which sent me down this path seem to have actually been due to the Bolt analytics associated collected for that call. In the scenario I was testing I have some 3,300 targets which I'm trying to add 6 specific facts from PuppetDB each to (the whole set of facts is unneeded and would be way too much) - which results in a little more than 20,000 add_facts calls. It seems when analytics is enabled it just falls over at some point when processing them. For a smaller but still large number of calls it just makes the add_facts calls start to take progressively (and significantly) more time to return. When I added analytics: false to the bolt-project.yaml it immediately started working and the performance was quite acceptable.

I was misled in my troubleshooting because it seems that analytics is not enabled when running bolt from a Git checkout instead of from the normal package. So, this change is probably still a good idea, but is quite incremental vs. revolutional as I had initially thought.

[donoghuc]

Thanks for reporting that. I've filed a bug issue and I intend on disabling analytics submissions by default moving forward. #3293