StateTracker: add new state tracking implementation.

This is simple and won't fit every use case, but it's a flexible
beginning and shouldn't be difficult to expand or speed up.

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
add really pathetic msgr test executable
test: Sketch out the initial MessengerDriver and TestDriver components.

For now these are super-simple with only a few orders, and
a bunch of those are marked "LATER". The first implementation we're
going to do won't even rely on the Messenger reporting any state
back; it'll just use the existing public interface.
Once that's done and works, we'll use StateTracker in the Messenger
and use that for the stuff marked LATER, then move on to more
sophisticated testing.

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
test: write an initial MessengerDriver implementation

It's pretty trivial right now, but that's okay for the moment!

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
test: write an initial TestDriver implementation

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
test: add a StateAlert class to the TestDriver interface

This lets us do async notifications.

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
test: set up a StateTracker for MessengerDrivers.

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
test: MessengerDriver implements its part of the alert system.

And TestDriver has a very simple run_tests sample.

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
test: change calling conventions in msgr TestDriver

Expecting tests to be based on subclasses is wrong. Instead, just
expose the management functions to the public. Then we can start
making it more capable of handling grunt work on its own.

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
StateTracker: extract State from StateTrackerImpl.

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
test: TestMsgr::connect_messengers takes two MDrivers

Nobody's going to be setting up connections to an endpoint they
don't control, right?

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
test: add lookup_state functions to TestDriver

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
test: add a unittest_msgr with the sample test.

Move the sample test to a new msgr_tests_functions header.
test: add more reporting states to MessengerDriver.

Unfortunately there's not yet a good way to trigger these; it'll
require introducing faults to the system.

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
test: add TestDriver::clean_up() to stop all the attached MDrivers.

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
test: extract the single-message send test from sample_test.

Make sample_test refer to it.

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
test: msgr new generate_message function

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
test: convert StateAlerts to be allocated by TestDriver.

Give them a reference to their lock as well, and let users either
specify a lock and Cond, or generate the data members. This
will make life easier on simple tests (which don't need to handle so
many objects), and on complicated tests (which will want to watch
for multiple alerts at once).

Convert current users.

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
test: enable Ceph debugging in test_msgrawesome.

Yay, messenger debugging output!

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>
test: add a test for mark_down behavior.

And add a wait_until_complete function instead of writing loops
continously.

Signed-off-by: Greg Farnum <gregory.farnum@dreamhost.com>