Schema validation fails on jinja template

good bug, needs wiring into cloudinit/handlers/jinja_template:render_jinja_payload_from_file I believe.

I think it's a little more complex than just wiring up. Schema validation doesn't only happen on systems which are the target for the cloud-config being validated (e.g. I could want to validate a schema which uses Azure-specific substitutions on my local (obviously-non-Azure) machine). And, more strongly than that, schema validation doesn't even only happen on systems where cloud-init has run or is installed (my dev machine doesn't have cloud-init installed). So we cannot assume that there will be any cloud-init data to substitute in and even if there _is_, we cannot assume that it is appropriate for use in the given cloud-config template.

As far as our schema is concerned, the specific values aren't important, it's just the types of the values that matter. So we can solve this by producing fake values for the variables in the template somehow. (We'll need to think about types a bit, but this isn't unachievable by any means.)

But we still have a problem: templates can have control flow. So a Jinja2 template can actually produce _structurally_ different cloud-configs, depending on the inputs to it. And, of course, the structure of cloud-config _is_ what the schema validates. I don't really have a great idea on how to handle this problem. That said, I think this applies to a small proportion of templates, so it's still absolutely worth enabling validation of the simple and common case on its own.

Pull request proposed upstream to render ## template: jinja content and validate schema of resulting #cloud-config user-data.

https://github.com/canonical/cloud-init/pull/2132

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3701

This bug is believed to be fixed in cloud-init in version 23.2. If this is still a problem for you, please make a comment and set the state back to New

Thank you.