Support pcs 0.10 syntax and Debian family with pcs

[towo]

Pull Request (PR) description

This PR adds nominal support for some new OSes:

• Debian 10
• Debian 11
• Ubuntu 18.04
• Ubuntu 20.04

It also allows for the new syntax of pcs encountered in newer releases (namely starting with 0.10.0).

In that context, there are

Breaking changes

1. version_corosync et al have been renamed to ensure_corosync (etc.) to better reflect what they're doing and reduce confusion.
2. The promotable and ms_metadata attributes have been removed from ms_metadata. I recommend explicitly defining the clone resources.

The reasoning for this is simple:

1. It's always ever been a shortcut; even pcs only aliases the promotable attribute on creation to creating the relevant resource manually. e.g. a clone
2. promotable is not an actual attribute of a primitive; thus assigning and parsing it involves looking at other objects to see if it's embedded in the relevant container resource.
3. Having two possible conflicting ways to achieve the same goal, in this case cs_primitive { 'foo': promotable => true } and cs_clone { foo-clone: primitive => 'foo'} is a sure-fire way of foot-shooting that will give issues with idempotency.

This Pull Request (PR) fixes the following issues

• n/a

[towo]

I'll try integrating #469 while I'm doing this anyway.

[bastelfreak]

since we only support 16 and newer, we don't need the else block?

[towo]

Well, thus far it still has legacy support for 14.04, thought it would be easy just to keep this in.

[towo]

There'll be commit cleanup, don't worry.

[bastelfreak]

@towo can you give it a try and rebase against our master?

[bastelfreak]

@towo can you give this another look please?

[towo]

There'll probably be some follow-up work for people thus inclined, I can add some issues for that. That'd be:

• Consider splitting up the pcs provider in old and new; ideally just have a common base provider and extend, if that's possible.
• There's some odd redundancies in the code that need to be refactored (i.e. thrown out).
• Generally figure out if there's a nicer way to split up the pcs/crm parts, so that we don't have to do as many inline evaluations.

[towo]

Little idempotency feedback from one of our Debian 10 systems:

Info: Using environment 'test_puppet_corosync'
Info: Applying configuration version '1640727887'
Notice: /Stage[main]/Profile::Base/Service[puppet-update.timer]/ensure: current_value 'running', should be 'stopped' (noop)
Notice: /Stage[main]/Corosync/Package[pcs]/ensure: current_value 'purged', should be 'present' (noop)
Notice: Class[Corosync]: Would have triggered 'refresh' from 1 event
[… unoptimized non-relevant stuff …]
Notice: Stage[main]: Would have triggered 'refresh' from 3 events

That's without changing anything, so it would (logically) assume the new pcs corosync::provider as a default, but see nothing wrong with the resources while still maintaining it with crm.

Settings corosync::provider to crm gives me a total noop.