Resolved onflicts in:
	ChangeLog
	src/or/config.c
	src/or/or.h

Specifically, admit that the "newconsensus" event exists, and
status/reachability has secretly been status/reachability-succeeded
all along, but nobody used it so we didn't notice.

* debian-merge:
  New upstream version
  bump to 0.2.1.19
  document my new relay-early behavior
  Changing MaxAdvertisedBW may not need a republish
  Write fingerprint to file and log without spaces
  Don't leak memory if we get too many create cells
  three hacks to workaround bug 1038

* commit 'tor-0.2.1.19':
  bump to 0.2.1.19
  document my new relay-early behavior
  Changing MaxAdvertisedBW may not need a republish
  Write fingerprint to file and log without spaces
  Don't leak memory if we get too many create cells
  three hacks to workaround bug 1038

also bring the release notes up to date

Sebastian Hahn authored 15 years ago and Roger Dingledine committed 15 years ago

Relays no longer publish a new server descriptor if they change
their MaxAdvertisedBandwidth config option but it doesn't end up
changing their advertised bandwidth numbers. Bugfix on 0.2.0.28-rc;
fixes bug 1026. Patch from Sebastian.

Now it will look like the fingerprints in our bridges documentation,
and confuse fewer users.

Specifically, every time we get a create cell but we have so many already
queued that we refuse it.

Bugfix on 0.2.0.19-alpha; fixes bug 1034. Reported by BarkerJr.

The problem is that clients and hidden services are receiving
relay_early cells, and they tear down the circuit.

Hack #1 is for rendezvous points to rewrite relay_early cells to
relay cells. That way there are never any incoming relay_early cells.

Hack #2 is for clients and hidden services to never send a relay_early
cell on an established rendezvous circuit. That works around rendezvous
points that haven't upgraded yet.

Hack #3 is for clients and hidden services to not tear down the circuit
when they receive an inbound relay_early cell. We already refuse extend
cells at clients.

When determining how long directory requests take or how long cells spend
in queues, we were comparing timestamps on microsecond detail only to
convert results to second or millisecond detail later on. But on 32-bit
architectures this means that 2^31 microseconds only cover time
differences of up to 36 minutes. Instead, compare timestamps on
millisecond detail.

* debian-merge:
  New upstream version
  bump to 0.2.1.18
  put in the full 0.2.1 release notes
  add a changelog entry for the upcoming 0.2.1.18
  make phobos's lines start with tabs again
  added LIBS=-lrt to Makefile.am for static libevent in the tor rpms.
  forward-port the 0.2.0.35 release notes
  add blurbs for recent release candidates
  Bump version to 0.2.1.17-rc-dev

* commit 'tor-0.2.1.18':
  bump to 0.2.1.18
  put in the full 0.2.1 release notes
  add a changelog entry for the upcoming 0.2.1.18
  make phobos's lines start with tabs again
  added LIBS=-lrt to Makefile.am for static libevent in the tor rpms.
  forward-port the 0.2.0.35 release notes
  add blurbs for recent release candidates
  Bump version to 0.2.1.17-rc-dev

Conflicts:
	ChangeLog

in case Make on openirix128 can't handle it otherwise

Now that we require EntryStatistics to be 1 for counting connecting
clients, unit tests need to set that config option, too.

Reported by Sebastian Hahn.