bcfg2-repo-validate should recognize Client tags in info.xml

[https://www.google.com/accounts/o8/id?id=AItOawkfHvWdYf7g8kSZA32s7dhK0Xig9JKo_CA]

A schema update is needed to make bcfg2-repo-validate aware of <Client> tags in info.xml files.

Unfortunately, there seems to be no proper way to express the desired properties in the XML Schema. (If only <xsd:all> allowed for elements with maxOccurs='unbounded'...)

I believe here needs to be a design choice made:

First option is to preserve the property that only one Info element is allowed. A disadvantage of this schema is that it imposes the following constraint on the info.xml files: any <Info>, <Group> and <Client> elements MUST appear in this exact order on every nested level to validate:

<FileInfo?>

<Info owner='...'/>

<Group name='...'>

<Group name='...'>

<Info owner='...'/>

</Group>

<Client name='...' negate='true'>

<Group name='...'>

<Info owner='...'/>

</Group>

<Client name='...'>

<Info owner='...'/>

</Client>

</Client>

<Client name='...'>

<Info owner='...'/>

</Client>

</Group>

<Client name='...'>

<Info owner='...'/>

</Client>

</FileInfo?>

(Notice that any <Client> entries on every nesting level appear after all <Group> entries, which in turn can be placed only after the optional <Info> entry.)

The second option allows for "out-of-order" placement of tags, but then we lose the requirement that at most one Info element is permitted. It feels more natural than the first approach, though.

The Bcfg2 engine doesn't care for element order nor Info count (it seems that the last matching <Info> wins if there are multiple), so any restrictions on XML syntax would be imposed purely by bcfg2-repo-validate, as before.

Patches implementing both approaches are attached.

/mkd

[https://www.google.com/accounts/o8/id?id=AItOawkfHvWdYf7g8kSZA32s7dhK0Xig9JKo_CA]

One more thing regarding proposed "in-order" solution. Assuring winning of the desired Info entry could be tricky if it is in a Group entry and there is a matching Client below. This applies when one wants to exploit that 'last Info wins' behavior, of course.

[https://www.google.com/accounts/o8/id?id=AItOawnSjgovXZr-_V3vGkvMSR0pc5LDykRc1Nc]

This was fixed independently in ​https://github.com/Bcfg2/bcfg2/commit/7cebd3f47926453bdac2b3f2c41804ac83358388