Migrate to major-based Scheme

[maxhoesel]

A little over a year ago, this collection introduced a lockstep versioning scheme where the collection version and the step-cli version were required to match. For example, the current version of this collection (0.24.5) requires step-cli>=0.24,<0.25.

This versioning scheme was a convenient way for this collection to ensure compatibility with the smallstep tools, but it had some major negative consequences:

• User flexibility: By requiring a specific version of step-clion every system, admins are forced to a specific step-cli version on all systems, and cannot upgrade to a newer version until this collection was updated
• Collection flexibility: Any breaking changes in this collection could only be introduced with a major release of step-cli, forcing us to combine additions for new step-cli versions with otherwise unrelated breaking changes.
• step-cli vs step-ca versions: By forcing a specific version of step-cli, the collection also indirectly affected the version of step-ca being run and implied guaranteed compatibility between the two. As far as I know there is no official compatibility guarantee from smallstep between different versions (I opened a discussion here), and I would argue that this is not a job this collection should be taking on anyway.

Most notably, this restriction just doesn't seem to be that necessary. step-cli 0.20 did introduce some breaking changes that affected the collection, but there have been no issues since then.

Finally, having an unstable collection version implies to users that the collection itself is changing rapidly - but this isn't really the case. Our module and roles have been reasonably stable and there is no reason for this to change soon.

All of these issues can be resolved by switching to an independent major versioning scheme, starting with collection version 1.0. Here is how this will work:

• The next release of the collection will be version 1.0.0
• Each major collection release will have a minimum supported step-cli version
  • This minimum version will be tested in CI, along with the latest step-cli release
• Newer versions of step-cli are assumed to be compatible, until an issue is discovered
• Any of the following will result in the release of a new major version
  • A breaking change in the collection content (modules, roles)
  • A breaking change in step-cli that is not possible to wrap around (such as the removal of a command)

Below is a list of the changes needed to introduce this versioning scheme in the collection:

• Rework the CI so that different smallstep tool versions can be tested.
• Update the collection docs to include compatible versions
• Rework the module version detection mechanism to look for the minimum version
• Decide on how to handle step-ca versions in the step_ca role - presumably step-ca will need a separate range of supported step-ca versions, along with its supported distros