add integration tests

[jmpesp]

Add integration_tests directory, with some basic tests. This was mostly added to
validate the work in #287 but was
ripped out to avoid merge conflicts.

Note that the integration tests specify a fixed port with a comment that says
that each port should be unique. I will do the work necessary to bind to
arbitrary ports in another PR - that way we can bind to port 0 and have the OS
select an open port for us.

[jmpesp]

Note - if we don't squash and merge, maybe the git history won't be wrecked by this PR?

[jmpesp]

opened issue #291

[leftwo]

Yeah, see if not squashing will preserve, that's what we want.

[leftwo]

Can we verify that if we don't squash it will keep history?

[jmpesp]

Can we verify that if we don't squash it will keep history?

I can try locally.

[jmpesp]

If I do what I believe is the "rebase and merge" strategy:

git checkout integration_tests
git rebase main
git checkout main
git merge --ff-only integration_tests

I believe that preserves history:

$ git annotate downstairs/src/lib.rs | head -n10
6efb3f1e	(Alan Hanson	2021-08-19 09:22:58 -0700	1)// Copyright 2021 Oxide Computer Company
231c3507	(Patrick Mooney	2022-04-07 13:03:56 -0500	2)#![cfg_attr(not(usdt_stable_asm), feature(asm))]
231c3507	(Patrick Mooney	2022-04-07 13:03:56 -0500	3)#![cfg_attr(
231c3507	(Patrick Mooney	2022-04-07 13:03:56 -0500	4)    all(target_os = "macos", not(usdt_stable_asm_sym)),
231c3507	(Patrick Mooney	2022-04-07 13:03:56 -0500	5)    feature(asm_sym)
231c3507	(Patrick Mooney	2022-04-07 13:03:56 -0500	6))]
231c3507	(Patrick Mooney	2022-04-07 13:03:56 -0500	7)
4c8cf92a	(Alan Hanson	2021-12-01 08:57:19 -0800	8)use futures::executor;
103333d2	(James MacMahon	2021-11-05 15:05:03 -0400	9)use futures::lock::{Mutex, MutexGuard};
f41900ec	(Alan Hanson	2021-08-18 08:56:45 -0700	10)use std::collections::HashMap;

[jmpesp]

But, from Github's docs:

When you select the Rebase and merge option on a pull request on GitHub.com, all commits from the topic branch (or head branch) are added onto the base branch individually without a merge commit. In that way, the rebase and merge behavior resembles a fast-forward merge by maintaining a linear project history. However, rebasing achieves this by re-writing the commit history on the base branch with new commits.

The rebase and merge behavior on GitHub deviates slightly from git rebase.

I'm going to do this manually