I've made an exception for cases where I'm sure that users can't
influence the inputs.  This is likely to cause a slowdown somewhere,
but it's safer to siphash everything and *then* look for cases to
optimize.

This patch doesn't actually get us any _benefit_ from siphash yet,
since we don't really randomize the key at any point.

Also, don't call the exit node 'reject *' unless our decision to pick
that node was based on a non-summarized version of that node's exit
policy.

rransom and arma came up with the ideas for this fix.

Fix for 7582; the summary-related part is a bugfix on 0.2.3.2-alpha.

This is meant to avoid conflict with the built-in log() function in
math.h.  It resolves ticket 7599.  First reported by dhill.

This was generated with the following perl script:

 #!/usr/bin/perl -w -i -p

 s/\blog\(LOG_(ERR|WARN|NOTICE|INFO|DEBUG)\s*,\s*/log_\L$1\(/g;

 s/\blog\(/tor_log\(/g;

This is an automatically generated commit, from the following perl script,
run with the options "-w -i -p".

  s/smartlist_string_num_isin/smartlist_contains_int_as_string/g;
  s/smartlist_string_isin((?:_case)?)/smartlist_contains_string$1/g;
  s/smartlist_digest_isin/smartlist_contains_digest/g;
  s/smartlist_isin/smartlist_contains/g;
  s/digestset_isin/digestset_contains/g;

IPv4-only exits have an implicit "reject [::]/0", which was making
policy_is_reject_star() return 1 for them, making us refuse to do
hostname lookups.

This fix chanes policy_is_reject_star() to ask about which family we meant.

Don't advertise an IPv6 exit policy, or accept IPv6 exit requests,
if IPv6Exit is not true.

Now, "accept *:80" means "accept all addresses on port 80", and not
just IPv4.  For just v4, say "accept *4:80"; for just v6 say "accept
*6:80".

We can parse these policies from torrc just fine, and we should be
successfully keeping them out of descriptors for now.

We also now include appropriate IPv6 addresses in "reject private:*"

By default, "*" means "All IPv4 addresses" with
tor_addr_parse_mask_ports, so I won't break anything.  But if the new
EXTENDED_STAR flag is provided, then * means "any address", *4 means
"any IPv4 address" (that is, 0.0.0.0/0), and "*6" means "any IPv6
address" (that is, [::]/0).

This is going to let us have a syntax for specifying exit policies in
torrc that won't drive people mad.

Also, add a bunch of unit tests for tor_addr_parse_mask_ports to test
these new features, and to increase coverage.

Clients now consider the ClientRejectInternalAddresses config option
when using a microdescriptor consensus stanza to decide whether
an exit relay would allow exiting to an internal address. Fixes
bug 7190; bugfix on 0.2.3.1-alpha.

Our implementation of parse_short_policy was screwed up: it would
ignore the last character of every short policy.  Obviously, that's
broken.

This patch fixes the busted behavior, and adds a bunch of unit tests
to make sure the rest of that function is okay.

Fixes bug 7192; fix on 0.2.3.1-alpha.

This can create a remote crash opportunity for/against directory
authorities.

The SMARTLIST_FOREACH macro is more convenient than BEGIN/END when
you have a nice short loop body, but using it for long bodies makes
your preprocessor tell the compiler that all the code is on the same
line.  That causes grief, since compiler warnings and debugger lines
will all refer to that one line.

So, here's a new style rule: SMARTLIST_FOREACH blocks need to be
short.

Fix for bug 5124.

Also, try to resolve some doxygen issues.  First, define a magic
"This is doxygen!" macro so that we take the correct branch in
various #if/#else/#endifs in order to get the right documentation.
Second, add in a few grouping @{ and @} entries in order to get some
variables and fields to get grouped together.

Fixes bug 4893.

These changes are pure mechanical, and were generated with this
perl script:

  /usr/bin/perl -w -i.bak -p

  s/crypto_pk_env_t/crypto_pk_t/g;
  s/crypto_dh_env_t/crypto_dh_t/g;
  s/crypto_cipher_env_t/crypto_cipher_t/g;
  s/crypto_digest_env_t/crypto_digest_t/g;

  s/aes_free_cipher/aes_cipher_free/g;
  s/crypto_free_cipher_env/crypto_cipher_free/g;
  s/crypto_free_digest_env/crypto_digest_free/g;
  s/crypto_free_pk_env/crypto_pk_free/g;

  s/_crypto_dh_env_get_dh/_crypto_dh_get_dh/g;
  s/_crypto_new_pk_env_rsa/_crypto_new_pk_from_rsa/g;
  s/_crypto_pk_env_get_evp_pkey/_crypto_pk_get_evp_pkey/g;
  s/_crypto_pk_env_get_rsa/_crypto_pk_get_rsa/g;

  s/crypto_new_cipher_env/crypto_cipher_new/g;
  s/crypto_new_digest_env/crypto_digest_new/g;
  s/crypto_new_digest256_env/crypto_digest256_new/g;
  s/crypto_new_pk_env/crypto_pk_new/g;

  s/crypto_create_crypto_env/crypto_cipher_new/g;

  s/connection_create_listener/connection_listener_new/g;
  s/smartlist_create/smartlist_new/g;
  s/transport_create/transport_new/g;

PLURAL() assumes that the plural is the canonical name for the option,
so now it is.

These were found by looking for tor_snprintf() instances that were
preceeded closely by tor_malloc(), though I probably converted some
more snprintfs as well.

(In every case, make sure that the length variable (if any) is
removed, renamed, or lowered, so that anything else that might have
assumed a longer buffer doesn't exist.)

Implements ticket #4207

Instead, use compare_tor_addr_to_node_policy everywhere.

One advantage of this is that compare_tor_addr_to_node_policy can
better distinguish 0.0.0.0 from "unknown", which caused a nasty bug
with microdesc users.

Previously, we had an issue where we'd treat an unknown address as
0, which turned into "0.0.0.0", which looked like a rejected
address.  This meant in practice that as soon as we started doing
comparisons of unknown uint32 addresses to short policies, we'd get
'rejected' right away.  Because of the circumstances under which
this would be called, it would only happen when we had local DNS
cached entries and we were looking to launch new circuits.

Nothing used it but the unit tests; everything else knows to use
compare_tor_addr_to_addr_policy instead.

A && A == A.

Found by frosty_un

This is a little error-prone when the local has a different type
from the parameter, and is very error-prone with both have the same
type.  Let's not do this.

Fixes CID #437,438,439,440,441.

This lets us make a lot of other stuff const, allows the compiler to
generate (slightly) better code, and will make me get slightly fewer
patches from folks who stick mutable stuff into or_options_t.

const: because not every input is an output!

This was harmless, we never compared it to anything but itself or 0.
But Coverity complained, and it had a point.

Patch from "postman" on trac. Fixes bg 2366. Bug on 0.1.2.5-alpha.

Found by piebeer.