Remove fragment support

[ml019]

Expected Behaviour

Extensions should be the official was to programmatically extension the configuration of a component.

Current Behaviour

Currently both fragments and extensions are supported. Fragments are harder to manage as they do not stand alone but need to be built into a case statement. They also don't permit the use of local variables, which then can cause issues if a variable name is used that is already in use in the framework e.g. settings.

Possible Solution

The hard option is to remove the current code that supports fragments.

A transitional strategy would be to make it a switchable feature with a default of off in one release (and the feature marked as deprecated) and then the flag removed in the next version.

Context

• reduce complexity of code base
• simplify configuration but providing one way to do a task

[roleyfoley]

I think this is currently blocked on the support for dynamic loading of extensions from CMDBs

To allow the use of local variables we could do the include as part of a fragment migration extension. That way the fragment when its included is part of a macro rather than an independent thing.

[roleyfoley]

I think that is related to #1443

[ml019]

Wrapping fragments in an extension is an interesting approach. I guess I was seeing fragments as a legacy thing we really wanted to get rid of and even if we wrapped them, it means the fragment code still need to be touched so why not just cut across to an extension and be done with it.

Agree re blocked on dynamic loading. That was just blocked on placement support which is there now so just needs includsion of placement info in the generation plan, and then file paths in the cmdb to then use that info in determining place in the state tree.