Refactor the usage of the settings class in specs and classes

When debugging the following issue https://github.com/elastic/logstash/issues/6868, I had to look everywhere in the code where the default workers settings were changed. The problem was raised in the `pipeline_spec`, but the values were changed in the `pipeline_pq_spec`.

We have to refactor our tests/classes to take into consideration that `SETTINGS` is a singleton,

**Possible Solutions**
- we pass a reference from the original instance to the differences classes
- or in our tests we make sure to clone the value and reset it for future run.

Start by comparing the pipeline_spec and pipeline_pq_spec mentioned in the issue, then trace how the singleton SETTINGS value is changed across the affected classes and tests. Check how the test suite handles settings between runs. Done means the tests and classes no longer leak modified settings into one another, using one of the proposed isolation approaches.

Written by the indexing model from the issue text.