commit bb7aa85ade67cecfec550e277e29359844ffd63d
author Jan Kundrát <jan.kundrat@cesnet.cz> Wed Aug 30 11:51:43 2023 +0200
committer Jan Kundrát <jan.kundrat@cesnet.cz> Wed Aug 30 12:00:59 2023 +0200
tree 4892c4ac18a1e3dec190ce9b3a975106b5c86f75
parent 03c77a1e1d8539070fca4928431b6ece6780c1a4

Add support for instance-identifier

My goal was at least to make basic R/O operation work with ietf-alarms.
Then I didn't have an easy way of testing this code, so I made it work
for editing as well.

Limitations:

- You can set an instance-identifier which points to an input node of an
  RPC/action, which sounds fishy, but that could be a libyang bug.

- Non-config lists works funnily, which might point to a bug somewhere
  in our handling of data paths:

 /> set example-schema:iid-valid /example-schema:users/userList
 libyang[0]: Unexpected XPath token "]" ("]"). (path: Data location "/example-schema:iid-valid".)
 libyang[0]: Invalid instance-identifier "/example-schema:users/userList[]" value - syntax error. (path: Data location "/example-schema:iid-valid".)
 The following errors occured:
  Message: Invalid instance-identifier "/example-schema:users/userList[]" value - syntax error.
  XPath: Data location "/example-schema:iid-valid".

- XPath says that any key value must be quoted, but the CLI reuses the
  existing leaf_data_ parser for list keys (even prior to this patch),
  which means that a list indexed by, say, an enum looks like:

  /example-schema/list[val=666]

  ...which is not a valid XPath. A valid XPath would look like this:

  /example-schema/list[val='666']

  This new feature hits the same problem; when the instance-identifier
  gets parsed from the user's input and converted to a string, the usual
  netconf-cli rules are followed, and the list keys are not quoted
  unless they are strings. This means that these values cannot be stored
  or committed because libyang correctly rejects unquoted key values in,
  say, instance-identifier values.

  Quite frankly I'm not even sure how come that this has not been a
  problem during normal operation, but perhaps it's only because we've
  always tested with string-based lists and nothing else. Sure, we have
  partial unit tests for all sorts of data types, but nothing actually
  checks the full stack from the parser's input all the way to a
  backend.

Path completion was a challenge for me to get right. At first I wanted
to use a different, fresh ParserContext to make sure that we do not
affect the main (leaf) path's state at all. That did not work well even
when I tried to copy the "relevant" memebrs of ParserContext back to the
original parser. But it turns out that simply reusing the existing
ParserContext works perfectly well. The only caveat is the concept of
"cwd", where a leaf below a certain container would "expect" paths that
are relative to the original cwd (which means "not root"). That's just
broken. The easiest fix is to always enforce an absolute path. The
easiest way of getting there was a yet another "parser mode" for
absolute-paths-only.

Yay for the immediately-invoked-lambda, because I really wanted to use
an constexpr if in there.

Change-Id: I68302ad854eab43aa6c42dcb2693b71ca3d2bd48
Depends-on: https://gerrit.cesnet.cz/c/CzechLight/dependencies/+/6445