cleanup the postfix code in puppet

our Puppet configuration in puppet is problematic in a few ways:

• main.cf hardcodes a lot of things (like smtp_dns_support_level, certificates, digest fingerprints, mynetworks, and more)
• master.cf and main.cf has host-specific configurations (e.g. eugeni, polyanthum) or role-specific (email::submission), instead of having this part of hiera
• transport maps are hardcoded in the module instead of (say) in a profile
• access control is difficult: it's unclear how to block a given email address (e.g. on RT/rude)
• the code is specific to our project and not reusable, and is therefore basically unmaintained (we should use an existing module instead)

so we should look at refactoring this to make it easier to expand and tweak.

The following projects are similar and we might want to collaborate with those in the future.

• voxpupuli/postfix - multiple issues, see below
• shared-puppet-modules-group/postfix - marked "LEGACY"
• cirrax/postfix - used by tails/puscii

There are multiple issues with the camptocamp (now voxpupuli) module that seemed to be deal-breakers during a quick evaluation:

• Changes to postfix::files causes a restart and reload - this is a performance concern: could be trouble for large servers
• Do not manage /etc/mailname - we remove this file in our configuration, so that's in direct conflict fixed!
• init.pp: use the postfix default for mydestination - this is a default that could be worked around (and we could just use a template for main.cf)
• main.cf empty - main.cf is completely empty by default, which is a major change from Debian (for example)

In general, it's unclear that the camptocamp brings enough benefit to justify switching to it at this stage. But since it's the most popular module and that it's actively maintained, it might be worth biting the bullet and adapting it to our needs instead of reinventing the wheel.

We should definitely look at the cirrax module, in any case, as we heard good things about it from fellow sysadmins.