refactor contactdb_api db access code after contractdb and uix stabilize

[bernhardreiter]

The current code in intelmq-mailgen:26f585021b6c5485c6ff7dea323306eed6ab012a
for contactdb_api uses database access strings that are similiar at places and could be refactored using more common functions.

It was a design choice to not produce more elegant code here, because the contactdb schema will be most likely changed as the upcoming new configuration method is fully implemented (and because of other lessons learned, like the inconsistencies found https://github.com/Intevation/intelmq/issues/18 and https://github.com/Intevation/intelmq/issues/19) In addition change is very likely after understanding the problem domain and use cases better with a running and working interface.

Very likely change in db structure and semantics, as potential changes in the user interfaces make better code coverage through tests unfeasable, it would be additional code to be potentially completely reworked.

If all the changes are done, the database access and the internal abstraction may be refactored.

[bernhardreiter]

It would also make sense to join database access in the bots/experts/certbund-contact (or at a different place). Right now the code does not separate and does not encapsulate the database layer. This has the advantage that changes are cheaper and can be one on the knowledge of how the database has to be driven. (Any abstraction would have been learned.) However the drawback is that code is scattered around different places that access the database.