Make type aliases stricter

[pegasd]

This PR makes the following changes:

• Start matching beginning and end of string instead of line (\A and \z instead of ^ and $)
• Add initially failing specs that pass with the changes
• Add specs for Stdlib::MAC type that were absent
• Leave the Stdlib::Compat::* types intact for compatibility purposes (is this correct behavior? or should I update those as well?)

[pegasd]

Let me elaborate a bit on that last point.

The Stdlib::Compat::* types emulate behavior of functions that reside in lib/puppet/parser/functions and users are discouraged from using them as they are considered to be legacy types.

However, I found out that Stdlib::Host uses Stdlib::Compat::Ip_address as one of the variants and that type looks like fair play.

So, the dilemma I have is whether we should update those types to be more restrictive and therefore more useful, but at the same time break compatibility? Maybe compatibility is overrated in this particular case?

[florindragos]

Hello @pegasd
Thanks for your contribution!
The fix looks good so far.
I assume you encountered issues where you had new lines and the regex did not match those. This would only break compatibility if someone was expecting it to not match new lines.
I'm not sure about the Stdlib::Compat::* types issue. Did you encounter a case where it is breaking compatibility?

[pegasd]

Hey there, @florindragos !
The main issue that I'm trying to solve with this PR is this: while one expects that Stdlib::Fqdn, for example, matches things like

example.com

in reality it also matches a multiline string like

RANDOM TRASH {}[]!!
example.com

more stuff
👌🏻

[pegasd]

By breaking compatibility I mean that if I update the Stdlib::Compat::* types, they will not match the behavior of corresponding functions.

I guess I could update those as well, but as I said, they're very much legacy and things may break for users in unexpected ways.

What do you propose? I can take a stab at compat if needed.

[pegasd]

Anything I can do to make this PR move along?

[carabasdaniel]

Hi @pegasd,
Thank you for your contribution, this looks good.