Light versec compiler CLI tool

[greetingsuniverse]

compiling function constraints has not been tested (function constraints are not implemented in ndnd yet)

[tianyuan129]

I used LLM to produce rules and it reported the the code behaves differently than python-ndn in the following cases. Can you verify?

1. A misspelled constraint silently removes the restriction

#key: "key"
#data: a & { typo: "allowed" } <= #key

python-ndn: rejects compilation: Pattern typo never occurs before.
Go: compiles; Check("/forbidden", "/key") returns true.

2. A function constraint changes the compiled model

#key: "key"
#data: a/b & { b: $eq(a) } <= #key

Result	python-ndn	Go PR
Compiles	Yes	Yes
$eq argument tag	1, referring to a	0, incorrect
Allowed signer for #data	#key	Signer constraint disappears
Check /x/x under /key	true with DEFAULT_USER_FNS	Panics: functions unsupported
Check /x/y under /key	false	Panics

3. A signing cycle passes Go’s model validation

#a: "a" <= #b
#b: "b" <= #a

python-ndn: constructing Checker rejects the signing cycle.
Go: NewLvsSchema accepts it; Check("/a", "/b") returns true.

5. A trailing comment breaks Go parsing

#key: "key"
#data: "data" <= #key // comment

python-ndn: compiles; check("/data", "/key") returns true.
Go: compilation panics with Expected NEWLINE, got EOF.

[greetingsuniverse]

I fixed 1 4 and 5

2. and 3. are in the LvsSchema class

to fix 2 (adding function constraint support) would break existing implementations that use it because of adding user functions list as an argument, or I can just add a separate function such as NewLvsSchemaFns that does the same thing but accepts user functions list also

3 is caused by the python-ndn checker sanity check which constructs the tree and traverses to detect this loop, ndnd doesn't but I'm not sure if allowing this behavior is really a big issue (the python-ndn compiler even allows it to compile)