[bug] ra_svn/Cyrus SASL hostname resolution failure when DNS server unavailable (e.g. when offline)

When not connected to the network, and not running named locally, I'm
getting a hostname resolution failure from ra_svn's Cyrus SASL
integration's usage of APR:

$ make svnserveautocheck
--- snip tests.log ---
START: basic_tests.py
CMD: svnadmin "create" "svn-test-work/local_tmp/repos" "--bdb-txn-nosync" <TIME = 0.088285>
CMD: svn "import" "--username" "jrandom" "--password" "rayjandom" "-m" "Log message for revision 1." "svn-test-work/local_tmp/greekfiles" "svn://127.0.0.1:32033/svn-test-work/local_tmp/repos" "--config-dir" "/home/dlr/src/subversion/subversion/tests/cmdline/svn-test-work/local_tmp/config" <TIME = 28.045649>
subversion/libsvn_ra_svn/cyrus_auth.c:721: (apr_err=670003)
svn: Temporary failure in name resolution
Traceback (most recent call last):
  File "/home/dlr/src/subversion/subversion/tests/cmdline/basic_tests.py", line 1816, in ?
    svntest.main.run_tests(test_list)
  File "/home/dlr/src/subversion/subversion/tests/cmdline/svntest/main.py", line 1012, in run_tests
    actions.setup_pristine_repository()
  File "/home/dlr/src/subversion/subversion/tests/cmdline/svntest/actions.py", line 96, in setup_pristine_repository
    main.greek_dump_dir, main.pristine_url)
  File "/home/dlr/src/subversion/subversion/tests/cmdline/svntest/main.py", line 359, in run_svn
    return run_command(svn_binary, error_expected, 0,
  File "/home/dlr/src/subversion/subversion/tests/cmdline/svntest/main.py", line 256, in run_command
    None, *varargs)
  File "/home/dlr/src/subversion/subversion/tests/cmdline/svntest/main.py", line 328, in run_command_stdin
    raise Failure
svntest.Failure
END: basic_tests.py
--- snip tests.log ---

(Note: My line numbers are a little off here.)
This is more simply reproduced by something like:

$ cd subversion/tests/cmdline/ && ./svnserveautocheck.sh basic

This is caused when svn_ra_svn__do_cyrus_auth() calls
get_remote_hostname(), which in turn calls apr_getnameinfo(); we're
apparently attempting to perform name resolution (e.g. via DNS lookup)
even when we already started with an IP address (e.g. 127.0.0.1), and
considering name resolution failure to equate to a hard error.

This bug appears to have been injected in r21109, during Garrett's
commit of a patch from Vlad.