python-hesiod should be agnostic to filsys types

[jdreed]

Python-hesiod knows "too much" about filsys types (this is a necessity of how/why it was created). At most, it should know how to prioritize FSGROUPs, and that the format of a filsys entry is "TYPE DATA-POSSIBLY-WITH-MORE-SPACES [PRIORITY]". It needn't know about filsys types, that's liblocker's job. Otherwise, when we add a new locker type, we'll need to teach two things about it, instead of just one.

[jdreed]

With the goal of fixing #227, I propose the following change to python-hesiod which retains backwards-compatibility by default:
 https://github.com/jdreed/python-hesiod/compare/liblocker-ng

[andersk]

“TYPE DATA-POSSIBLY-WITH-MORE-SPACES [PRIORITY]” is an ambiguous grammar. You can’t tell whether something that looks like PRIORITY might actually be part of DATA-POSSIBLY-WITH-MORE-SPACES without knowing more about the latter.

[jdreed]

Point, though I omitted that PRIORITY is present iff more than one result is returned. (As I say that, I sincerely hope there are not any FSGROUPS with only one member).

Relatedly, unicast discussion with Evan suggests it would be fine for Debathena to be upstream for python-hesiod.

[jdreed]

 https://github.com/mit-athena/python-hesiod/pull/1

I'm aware of  https://github.com/achernya/hesiod/pull/3, but in the magical world of DVCS, these should not block on each other.

[jdreed]

_Of course_ there exist FSGROUPS with one member. So python-hesiod really shouldn't pretend to know about FSGROUPs at all, but we do what we must, because we can.
 https://github.com/mit-athena/python-hesiod/pull/2

[jdreed]

This went to production a while ago.