Feature: cibadmin: render access mode for selected user

[jnpkrn]

Known rough edges:

• [x] fix oddities spotted by Ken
• [x] missing deployment stuff (Makefile/spec) for new acls-render.xsl
• [x] cibadmin's help should show an example usage
• [x] not tested user friendliness under all circumstances (-U required etc.)
• [x] no CLI tests
• [ ] public API not reflecting the intent to generalize for groups alike (worked on)
• [x] check that we are working with eligible schema (to begin with)

[jnpkrn]

and actually meant to take a look at irking sync/async handling redundancy for output (to this point, was only testing with sync/-s)

[jnpkrn]

2.5 (2.9) points from the initial list is still somewhat missing, but shall work better now, and be close to the final version.

[jnpkrn]

Was a PoC originally, but got fully baked as it was quite a furious struggle to put the public API nits of undocumented libxslt introspection (and manipulation) together, assisted with XML catalog technique we already had experience with from the build system to workaround some Pulibcan quirks.

May immediate benefit for us: the feature in cibadmin readily workable from checkout and subsequent build (i.e., in developmental mode).

Will get back to the original feedback, yet.

[jnpkrn]

I attempted to avoid any global state mangling and per-document (or rathar, per parser context) catalogs were very promissing. Unfortunately, it was a dead end, for the last "millimeter" piece in chain missing (xsltDocDefaultLoaderFunc not adopting existing context but creating a default, non-customized one anew, even if the context object gets passed into it!).

So the global state needs to be modified regardless. Externalized catalog file and mangling with per-process globally visible environment variable is hefty and error-prone, so eventually the solution is to install a custom document loader that will intercept and rewrite particular URI on the fly, then deferring to the previously installed (presumably default) document loader.

[jnpkrn]

Travis-CI, MAINT=1:

Relax-NG validity error : Extra element choice in interleave pacemaker-acls-3.0.rng:10: element choice: Relax-NG validity error : Element attribute failed to validate content pacemaker-acls-3.0.rng:9: element optional: Relax-NG validity error : Invalid sequence in interleave pacemaker-acls-3.0.rng:9: element optional: Relax-NG validity error : Element optional failed to validate content pacemaker-acls-3.0.rng:8: element interleave: Relax-NG validity error : Invalid sequence in interleave Relax-NG validity error : Extra element define in interleave pacemaker-acls-3.0.rng:5: element define: Relax-NG validity error : Element grammar failed to validate content pacemaker-acls-3.0.rng fails to validate

This is exactly the manifestation of libxml2 bug identified, fixed, and hence eventually going away:

https://gitlab.gnome.org/GNOME/libxml2/merge_requests/31

Will silence this out for the time being.

[kgaillot]

FYI, I cherry-picked the "restrictive usage", "serializer reinventing", and "get_schema_path" commits into #1914 so they get exercised in 2.0.3-rc1. The remainder of this can remain against master branch.

[jnpkrn]

Rebased on top of #1943 with some tweaks and fixes.

Most importantly, I decided to refrain from acls in parts directly facing the user: the switch is now --access-render, which is substantially more user friendly, as it touches the merit of the action directly (rather than via obnoxious TLA, which is moreover not a proper fit here as documented).

To immediately fix:

• superfluous, directory specific message in ./cts-cli access_render

• acl-2-render.xsl doesn't restore the color after returning from tag correctly in all cases (as attested with said test suite easily)

[jnpkrn]

Mentioned and couple of more issues were fixed and some more tweaks and rectifications absorbed.