Suspected cause: multicasting not working for nodes with
an interface 0 due to lack of 'mirroring_add 0 0' line in
hp4commands.txt

Three modes of bit_xor supported, two of which are needed
by VIBRANT.

It is glorious

And it is super awesome

One thing left for VIBRANT support - modify_field_rng_uniform

Should be a can of cake

Unfortunately, remove_header is broken.  But add_header works
and it is awesome.

ISSUES.md can track all known issues, starting with the
fact that parse_ctrl.state should be a match parameter
in match.p4t tables, as a ternary match since it won't
be needed all the time.

Better alignment with recent compiler work

Some large fields are sometimes used in operations that
won't work on Agilio cards, per their specs

We've applied a fix to p4_hp4 but are not yet sure it is
correct in all cases; test_select.txt includes some
p4_hp4 data structures to look at following
generation of tset_pipeline_config entries

Current codebase supports the following configurations, where
the first number is the number of stages supported, and the
second number is the max number of primitives per stage
supported:
- 2 x 9
- 3 x 8
- 4 x 5
- 5 x 4
- 6 x 3
- 8 x 2
- 9 x 1
...as well as any configuration smaller in at least one dimension
than one of the listed configurations.

Number of actions does not change with hp4's configuration in
terms of the number of stages and primitives supported.  The
total number of actions is currently 150 and only changes
as we modify P4 support.  This number is well under Agilio's
limit of 256 actions.

Generates all hp4 configurations 1-X by 1-Y, where X is
the number of stages supported, and Y is the max number
of primitives per stage supported.  Then counts the
total number of actions defined per configuration, and
collects results across all configurations into a .csv.

The test reveals that p4_hp4 does not properly handle
this type of parser return statement yet; ongoing analysis
is in tests/analysis/test_select.txt.

Unwanted output noted in previous commit was result of forgetting
that the hp4controller modules had been installed to /usr/local/...
via setuptools (setup.py in hp4-ctrl), so the modules being
accessed were not the ones I was modifying in my home directory.

To more easily modify these files and run tests, instead of
using setuptools we modify PYTHONPATH in .profile in the home
directory.  We must also modify sudoers to preserve the
environment when running commands via sudo, because the
test requires the use of sudo, because of mininet.

We should add basic instructions to this effect.

Can't figure out why getting unwanted output during tests...

Demo: HP4 running test_hub; two tests:
- h1 ping h2 (expected: success)
- h1 ping h3 (expected: fail)
Both tests return the expected results.

To run: sudo ./test.py.

Additional tests may be added with 1-3 files per need:
- <proj>.p4
- [<proj>.commands] -- bmv2 runtime table management commands
- [<proj>.py] -- test cases + mininet script

If the <proj>.py file is not present, the framework uses
test_mininet.py with the two tests described above (h1 ping h2,
h1 ping h3).

Realized we can simply pass the name of the script file to
the CLI initializer via the script= parameter

Add mininet script argument for automating mn commands

Action handling now involves checking whether
meta_primitive_state.primitive[+Y+] == 0 between primitives,
which indicates no further primitives remain, but that value
was used to indicate a modify_field primitive, so the value
for modify_field has been changed.

Requires update to compiler in hp4-ctrl repository

This folder housed old tests that have long since
been rendered obsolete by 1) changes to HyPer4;
and 2) the controller repository (hp4-ctrl:
git@gitlab.flux.utah.edu:hp4/hp4-ctrl.git).

Saved two analysis scripts that may yet be useful
in hp4/analysis.