Deduplicate Qt plugins deployment

[dantti]

Sorry I added pre-commit locally to make sure clang-format was run and apparently your sources were not in sync with it

[dantti]

I have update with my .clang-format but still a bit different, I can manually fix it by hand :(, but I'd rather wait for your review and input about code style :)

[TheAssassin]

This PR is unfortunately not acceptable because one cannot even tell what changes you implemented. You should never just run an autoformatter you like on an entire code base and the PR it.

Feel free to fix the PR and provide just the changes you want to propose. But, generally, I advise people to open issues first.

[dantti]

as I said I thought this project had .clang-format, it's a pain to work with projects that don't, and pre-commit just makes sure maintainers don't need to keed pointing to style issues which I have seen you pointing at on another PR.

I there was a proper style file I could just rebase and the PR would be fine.

[dantti]

@TheAssassin done, I didn't bother to remove the using namespace .. which is not in use anymore, I can remove if you like...

[dantti]

Basically, most deployers had the same code that I moved into BasicPluginsDeployer::deploy() and read what was changing in each deployer with the list from qtPluginsToBeDeployed, for the corner cases where there was more logic BasicPluginsDeployer::customDeploy() is called with no need to call the base class as the code should go to BasicPluginsDeployer::deploy().

[bjorn]

It's a nice cleanup, but instead of introducing this code here along with the qtPluginsToBeDeployed function, I would suggest to introduce a protected BasicPluginsDeployer::deployPlugins(const std::vector<std::string> &plugins), so in each deploy() implementation one could just do for example:

    deployPlugins({"bearer"});

I think that's adding a bit less complexity overall, since it removes the need for both qtPluginsToBeDeployed and customDeploy.

[dantti]

while a deployStandardQtPlugins() could be nice indeed having a customDeploy() or if going with this function then maybe doDeploy() is a better naming, this is because we override methods and current code was calling the base method which makes the code slower due extra branching and is error prone as one has to remember to call that.
So I'll add a new commit and we see what is best.

[bjorn]

Yeah, that's better and I do think it's nice how doDeploy allows to get rid of all the calls to the superclass. Though I would personally just have removed them, along with the base implementation, because "we might add more functionality later on" is not a good reason for all that cruft in my opinion.

Anyway, this patch is a good clean-up as-is in my opinion.