Part of 21581.

(But use bash if it's available.)
This is a workaround until we remove bash-specific code in 19699.

Fixes bug 21581; bugfix on 21562, not in any released version of tor.

This is an "ours" merge to avoid a version bump.

This is an "ours" merge to avoid a version bump.

This is an "ours" merge to avoid taking a version bump

This is an "ours" merge to avoid taking a version bump, and to
avoid replaying the post-0.2.7.6 history of "maint-0.2.7-redux" onto maint-0.2.8, which already included the relevant changes.

"ours" merge to avoid version bumps

"ours" merge to avoid version bumps

"ours" merge to avoid bumping version

Previously I'd made a bad assumption in the implementation of
prop271 in 0.3.0.1-alpha: I'd assumed that there couldn't be two
guards with the same identity.  That's true for non-bridges, but in
the bridge case, we allow two bridges to have the same ID if they
have different addr:port combinations -- in order to have the same
bridge ID running multiple PTs.

Fortunately, this assumption wasn't deeply ingrained: we stop
enforcing the "one guard per ID" rule in the bridge case, and
instead enforce "one guard per <id,addr,port>".

We also needed to tweak our implementation of
get_bridge_info_for_guard, since it made the same incorrect
assumption.

Fixes bug 21027; bugfix on 0.3.0.1-alpha.

This feature makes it possible to turn off memory sentinels (like
those used for safety in buffers.c and memarea.c) when fuzzing, so
that we can catch bugs that they would otherwise prevent.

Since 0.2.4.11-alpha (in 01966479) we've tried to randomize
the start time to up to some time in the past.  But unfortunately we
allowed the start time to be in the future as well, which isn't
really legit.

The new behavior lets the start time be be up to
MAX(cert_lifetime-2days, 0) in the past, but never in the future.

Fixes bug 21420; bugfix on 0.2.4.11-alpha.