Mode 6 filter removal considered harmful

[Achim Gratz]

As already briefly mentioned on IRC, the way the mode 6 messaging was
changed to do no filtering at all anymore doesn't really work nicely.
To wit here are two otherwise identical systems, one with and the other
without those changes getting asked for their system variables:

--8<---------------cut here---------------start------------->8---
tinkerboard1
status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
leap=00, stratum=1, precision=-20, rootdelay=0.0, rootdisp=1.03, refid=NavS,
reftime=e037b623.b0b9a752 2019-03-16T17:51:31.690Z, tc=4, peer=27112,
offset=0.000137, frequency=9.903748, sys_jitter=0.000197,
clk_jitter=0.000149, clock=e037b626.08301d6f 2019-03-16T17:51:34.031Z,
processor="armv7l", system="Linux/4.4.71ag1+",
version="ntpd ntpsec-1.1.3+ 2019-03-09T20:22:13Z (git rev cfa4495b2)",
clk_wander=2.7e-05,
sys_var_list="leap,stratum,precision,rootdelay,rootdisp,refid,reftime,tc,peer,offset,frequency,sys_jitter,clk_jitter,clock,processor,system,version,clk_wander,sys_var_list,tai,leapsec,expire,mintc,mru_enabled,mru_depth,mru_deepest,mru_mindepth,mru_maxage,mru_minage,mru_maxdepth,mru_mem,mru_maxmem,ss_uptime,ss_reset,ss_received,ss_thisver,ss_oldver,ss_badformat,ss_badauth,ss_declined,ss_restricted,ss_limited,ss_kodsent,ss_processed,peeradr,peermode,authdelay",
mintc=0, mru_enabled=1, mru_depth=13, mru_deepest=13, mru_mindepth=600,
mru_maxage=3600, mru_minage=64, mru_maxdepth=14563, mru_mem=1,
mru_maxmem=1024, ss_uptime=595715, ss_reset=595715, ss_received=493485,
ss_thisver=489366, ss_oldver=0, ss_badformat=0, ss_badauth=0, ss_declined=0,
ss_restricted=0, ss_limited=0, ss_kodsent=0, ss_processed=493484,
peeradr=127.127.20.0:123, peermode=3, authdelay=0.06, authkeys=1,
authfreek=15, authklookups=0, authknotfound=0, authencrypts=0,
authdigestencrypts=0, authcmacencrypts=0, authdecrypts=0, authreset=595715,
koffset=0.00013, kfreq=9.90375, kmaxerr=0.0025, kesterr=0,
kstflags="pll nano", ktimeconst=4, kprecis=1e-06, kfreqtol=500, kppsfreq=0,
kppsstab=0, kppsjitter=0, kppscalibdur=0, kppscalibs=0, kppscaliberrs=0,
kppsjitexc=0, kppsstbexc=0, iostats_reset=595715, total_rbuf=10, free_rbuf=9,
used_rbuf=0, rbuf_lowater=1, io_dropped=0, io_ignored=0, io_received=1684914,
io_sent=501688, io_sendfailed=0, io_wakeups=1088905, io_goodwakeups=1088905,
timerstats_reset=595715, timer_overruns=0, timer_xmts=0, fuzz=0.001166,
clk_wander_threshold=0.1, mru_exists=493472, mru_new=13, mru_recycleold=0,
mru_recyclefull=0, mru_none=0, mru_oldest_age=17322, tick=0.001166,
ss_numctlreq=4119, rootdist=1.0, authdigestdecrypts=0, authdigestfails=0,
authcmacdecrypts=0, authcmacfails=0, lockclock=0, nts_client_send=0,
nts_client_recv=0, nts_client_recv_bad=0, nts_server_send=0,
nts_server_recv=0, nts_server_recv_bad=0, nts_cookie_make=0,
nts_cookie_decode=0, nts_cookie_decode_old=0, nts_cookie_decode_too_old=0,
nts_cookie_decode_error=0, nts_ke_serves=0, nts_ke_serves_bad=0,
nts_ke_probes=0, nts_ke_probes_bad=0,
daemon_version="ntpd ntpsec-1.1.3+ 2019-03-09T20:22:13Z (git rev cfa4495b2)"
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
tinkerboard2
status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
version="ntpd ntpsec-1.1.3+ 2019-01-21T16:54:13Z (git rev 6c029ef4c)",
processor="armv7l", system="Linux/4.4.103ag+", leap=00, stratum=1,
precision=-20, rootdelay=0.0, rootdisp=1.06, refid=NavS,
reftime=e037b621.c88451db 2019-03-16T17:51:29.783Z,
clock=e037b626.8193e906 2019-03-16T17:51:34.506Z, peer=18883, tc=4, mintc=0,
offset=-0.000504, frequency=10.187485, sys_jitter=0.000633,
clk_jitter=0.000353, clk_wander=6.8e-05
--8<---------------cut here---------------end--------------->8---

Can the offending two commits (ee4ce108 removes the filtering, 4c5a32fb
removes the flag bits the filtering was based on) be reverted and
something more sensible be discussed here and then implemented.  And no,
neither is the first commit a "Feature", quite the contrary, nor the
second a "Refactor".  Both remove a feature or code, don't add or
re-arrange.

I haven't checked extensively if the list feature still works that
allows to flag a user-selected set of variables for output, which can
then be used with rl / cl variants of the cv / rv commands; the basics
still seem to be there.  One of the problems is that there is only one
list that gets applied to both the system and the clock variables.  So a
useful feature would be if such lists could be named.  If that feature
works, then predefined lists containing all system and clock variables
(the output of a query for sys_var_list on the appropriate association
ID) could be provided to achieve the "no filters" output more easily and
directly.  Alternatively, extra variants for rv and cv could be provided
to do the two queries for the user.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada