APR hash order

A recent APR change affects hashes: the default hash function now has a
random component. This change was made to avoid possible DOS attacks
where the user controls input to the hash. If the user selects inputs
that all collide then subsequent hash access becomes O(N) rather than
O(1). The random component makes this attack harder, although it may
not prevent it.

In a number of places Subversion iterates over hashes in hash order and
so the order is now different. Things like the order of properties in
proplist, the order of children in an update, etc. Not only is the
order now different from previous releases but the order can also vary
from run to run. Most of the time this doesn't matter, one hash order
is as good as another, but it has caused a few failures in our
regression testsuite where a test depended on a particular hash order.

For things like 'proplist' where the output lines are in an arbitrary
order using UnorderedOutput is the right fix.

Here's a typical FAIL in diff_tests.py 14:

--- EXPECTED
+++ ACTUAL
@@ -1,9 +1,3 @@
-Index: svn-test-work/working_copies/diff_tests-14/iota
-===================================================================
-@@ -1,3 +1,2 @@
- This is the file 'iota'.
- some rev2 iota text.
--an iota local mod.
 Index: svn-test-work/working_copies/diff_tests-14/A/mu
 ===================================================================
 @@ -0,0 +1 @@
@@ -12,3 +6,9 @@
 ===================================================================
 @@ -1 +0,0 @@
 -Contents of newfile
+Index: svn-test-work/working_copies/diff_tests-14/iota
+===================================================================
+@@ -1,3 +1,2 @@
+ This is the file 'iota'.
+ some rev2 iota text.
+-an iota local mod.

I've used UnorderedOutput here as well. I suppose a more rigourous fix
would be to write some sort of UnorderedDiff code but I'm not sure where
or how.

The remaining FAILs are mostly of two kinds: differences in XML status
and differences in dumpfile order. The first can be fixed by writing
run_and_verify_status_xml and parsing the XML as already done in
run_and_verify_log_xml. It's mostly a matter of deciding how much of
the log XML parsing code can be reused.

The dumpfile order is more interesting. Although we don't specify the
dumpfile order until now it has been repeatable, at least when using the
same executable/libraries. I can see that this repeatability is useful
to an administrator. Rather than fixing the testsuite to ignore
dumpfile order changes perhaps we should remove the random behaviour and
continue to provide repeatable dumpfiles? This would involve using
apr_hash_make_custom rather than apr_hash_make. I don't know whether
it's possible to do that just for dump, or whether it would affect other
operations.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com