pkg/apis/nfd: stricter format checking for template labels

[marquiz]

Require that the expanded LabelsTemplate has values. That is, the
(expanded) template must consist of key=value pairs separated by
newlines. No default value will be assigned and we now return an error
if a (non-empty) line not conforming with the key=value format is
encountered.

Commit c8d7366 described that the value defaults to "true" if not
specified. That was not the case and we defaulted to an empty string,
instead.

An example:

  - name: "my rule"
    labelsTemplate: |
      my.label.1=foo
      my.label.2=

Would create these labels:

  "my.label.1": "foo"
  "my.label.2": ""

Further, the following:

  - name: "my failing rule"
    labelsTemplate: |
      my.label.3

will cause an error in the rule processing.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: marquiz

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [marquiz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[marquiz]

An alternative to solution would be to ditch the default value ("true") and e.g. just error out if the value part is missing (i.e. the expanded template value does not have an equals sign). I'm fine with that solution, too, if people like it more. The reasoning behind the default "true" value is that it aligns with the format of hooks and feature files

[marquiz]

Will change this
/hold

[marquiz]

An alternative to solution would be to ditch the default value ("true") and e.g. just error out if the value part is missing (i.e. the expanded template value does not have an equals sign).

Changed the PR to behave like this.

/unhold

[zvonkok]

We can make the API more restrictive and loosen up when needed, the other way around could be problematic.
Like this way much better.

/lgtm