getDevicePCIAddress() has pretty confusing semantics.  Both its input
and output are in other parts of the code described as a "PCI
address", but neither is *actually* a PCI address (in the standard
DDDD:BB:DD.F format).

What it's really about is resolving a "PCI path" - that is way to
locate a PCI device by using it's slot number and the slot number of
the bridge leading to it - into a sysfs path.

Rename the function, and change a bunch of variable names to make
those semantics clearer.

Signed-off-by: David Gibson <[email protected]>

pciPathToSysfs takes a PCI path, with a particular format.  A number
of places implicitly need strings in that format, many of them repeat
the description.  To make things safer and briefer create a newtype
wrapper for strings in this format, and just describe the internals at
the type definition.

Then, update variable names and comments throughout to call things in
this format "PCI path", rather than "PCI identifier", which is vague
or "PCI address" which is just plain wrong.  Likewise we change names and
comments which incorrectly refer to sysfs paths as a "PCI address".

This changes the grpc proto definitions, but because it's just
changing the name of a field without changing the field number, it
shouldn't change the actual protocol.  It also trivially changes the
copyright notice, because Travis whinges otherwise.

Signed-off-by: David Gibson <[email protected]>

This does some general reorganization of TestPciPathToSysfs.  It tests the
same things (plus a few trivial extras), but is set out in a way that will
be easier to extend when we broaden the allowed pciPath values we accept.

It also removes some intermediate variables that seemed to make things
harder rather than easier to follow.

Signed-off-by: David Gibson <[email protected]>

Currently pciPathToSysfsImpl, which translates PCI paths into sysfs paths
accepts only pci paths with exactly 2 components; which represents PCI
devices separated from the root bus by exactly one PCI to PCI bridge (which
could be a virtual P2P bridge, such as a PCI-E root port).

There are cases we might reasonably want to support which have devices
either plugged directly into the root bus (zero bridges), or under
multiple layers of P2P bridge (a PCI-E switch would require at least 2
layers).

So, generalize pciPathToSysfs to support any number of components in the
PCI path.

We need to adjust some tests to match, not only because of the intended
change in behaviour, but also because the new version probes sysfs a bit
differently, so we need to mock things to match.

fixes #854

Signed-off-by: David Gibson <[email protected]>