Initial schema sketch for email templates

[scotttrinh]

Some discussion points:

1. Should the fallback template be encoded in the schema (seems messy...) or in the rendering code?
2. Should we relate the SMTPConfig to these templates somehow?
3. Somewhat related: I wonder if there is a way to require SMTPConfig if you have any of the email factors enabled? 🤔

[scotttrinh]

@elprans I wanted to check and see if this is what you had in mind based on our discussion earlier today:

Suggested change

	create type ext::auth::EmailTemplate extending cfg::ConfigObject {
	create required property subject: std::str {
	create annotation std::description :=
	"Subject of the email.";
	};
	create required property html: std::str {
	create annotation std::description :=
	"Body of the email.";
	};
	create required property plain_text: std::str {
	create annotation std::description :=
	"Body of the email in plain text.";
	};
	};
	create type ext::auth::EmailTemplate extending cfg::ConfigObject {
	create required property purpose: std::str {
	create constraint exclusive;
	};
	create required property subject: std::str {
	create annotation std::description :=
	"Subject of the email.";
	};
	create required property html: std::str {
	create annotation std::description :=
	"Body of the email.";
	};
	create required property plain_text: std::str {
	create annotation std::description :=
	"Body of the email in plain text.";
	};
	};

And then adding multi email_templates: ext::auth::EmailTemplate; to the existing AuthConfig object?

[elprans]

One advantage of the original link approach is that we can populate some default and make them required for robustness?

[scotttrinh]

Yeah, I thought about default here, but I was wondering if a huge blob of HTML is really something we want to have in the schema. Also might be nice to have the default HTML be something that we "upgrade" over time without having to require a schema change.