Switching to in module hiera data & updating docs

[genebean]

This PR does the following:

• Switched from Hiera backend to standard function
• Created a function for determining the needed PuppetDB metrics based
  on PE version
• Removed the variable 'storage_metrics_db_queries' since it was not
  referenced anywhere.
• Updated the README and documentation in some manifests

This all stemmed from trying to solve the problem of having to define
the same values for parameter defaults in multiple places. The part of
this PR that addresses that exact problem is the new
puppet_metrics_dashboard::puppetdb_metrics() function. The rest of this
was just a by-product of getting to that solution.

[suckatrash]

This looks great! Just one question below

[npwalker]

Does module_data work for users still on hiera 3?

I think the function is overkill and makes figuring out defaults significantly more complicated than just leaving it as it was. I believe the best practice on module data allows for still using params.pp when it is inconvenient to use module data.

[genebean]

The problem being solved here @npwalker is centered around the user not having to define the puppetdb_metrics in their own hiera as @suckatrash was unable to get a defined type to use what was in params.pp.

[genebean]

@npwalker I believe module data is a Hiera 5 thing: https://puppet.com/docs/puppet/6.6/hiera_migrate.html#adding-hiera-data-to-a-module

[suckatrash]

@npwalker Docs tell me "You can even start using some Hiera 5 features—like module data—without upgrading anything." ...I forget how that works exactly, but it's notable that the puppetlabs-ntp module doesn't use params.pp at all.

As @genebean mentioned, this solves an important problem: we need parameter defaults to be available in one of the defined types puppet_metrics_dashboard::profile::puppetdb (when it's applied outside of any other class in this module) and there doesn't seem to be a great way to do that without a solution like this.

[npwalker]

Ah the reason for the change isn't clear. If it were me I would have just made two functions, one to return the timeout and one to return the puppetdb_metrics hash instead of going into module_data and involving hiera.

For puppetdb_metrics I think that's still the correct solution. There's seemingly no reason to involve hiera to get that hash when you can just call the function directly.

[suckatrash]

The reason I like having the default params in hiera is that it's far easier to access the values without including the params class. With the defined types being introduced in #62, we might want to access other default values in the future, and module_data just seems the way to go to me.

[genebean]

I believe I am finished reworking this PR. I have also updated the commit message and the top comment.