autofs::map has issues when order not set

[dhollinger]

The autofs::map defined type will completely replace the contents of the target concat file if the order parameter is not set. This is because the concat::fragment set within both autofs::mount and autofs::map default to 1, which will cause concat to replace the content in that location (in the case of autofs::map it will replace the entire array that was laid down in autofs::mount).

My suggestion to @traylenator is that autofs::map should be a wholly separate defined type that does not interact with anything laid down by autofs::mount, otherwise we end up with redundant code and functionality.

If the concern is adding additional lines to an existing file, updating the array in the code or, better yet, in the hieradata is the appropriate place to do so.

If the concern is the ability to manage a mapfile outside of the autofs::mount block, then let's make the autofs::map file a completely separate define type meant to be called standalone.

Additionally, we could completely remove mapfile concat code in autofs::mount and instead have autofs::mount call autofs::map

[dhollinger]

@traylenator if you don't have time to work this, I can update the code as well.

[traylenator]

As a comment, having two concat::fragments with the same order is just fine, loads of stuff would not work.

[jcbollinger]

It was a fine idea to make autofs::map a separate defined type, but it seems not to have been a good idea to put responsibility for overall map file management there. That opened up an avenue for inconsistency to be introduced, both between different autofs::map instances, and between autofs::mounts and autofs::maps. As it ended up being implemented, such inconsistencies actually arise under relatively mundane circumstances.