Description of problem:
    With flag "-aX", rsync creates xattr data structure, but does not free
    it when done.  This leads to 200 bytes of memory leak for each file
    and each dir, or a few giga for my big backup job.

    In free_xattr(), we have
        rsync_xal_free(sxp->xattr);
        free(sxp->xattr);
        sxp->xattr = NULL;
    In rsync_xal_free() we should also free the pointer to allocated memory:
        rsync_xa *rxas = xalp->items;  // "xalp" is "sxp->xattr"
        free(rxas);            <== need to add this line
        xalp->items = NULL;    <== for good practice.
        xalp->count = 0;
    because xalp->items comes from malloc() earlier in expand_item_list():
        new_ptr = _realloc_array(...); // wrapper of malloc() and realloc()
        lp->items = new_ptr;

Version-Release number of selected component (if applicable):
    rsync-3.0.8-1.fc14.x86_64

How reproducible:
    always, with "-aX" flag.

Steps to Reproduce:
1. create a few source files
    d1=/tmp/t1
    d2=/tmp/t2
    mkdir $d1
    cd    $d1
    for i in {1..40}; do mkdir -p $i; echo 123 > $i/a$i; cp $i/a$i $i/b$i; done

2. use valgrind to check for memory leak
    rm -rf $d2; 
    valgrind --leak-check=full rsync -aX $d1/ $d2/

Actual results:
    valgrind indicates memory leak.

Expected results:
    no memory leak, at least no big ones.

Additional info:
  - valgrind reports 200 bytes leak for each file processed:

    16,000 bytes in 80 blocks are definitely lost in loss record 25 of 28
       at 0x4A05E46: malloc (vg_replace_malloc.c:195)
       by 0x41E1D6: _realloc_array (util.c:1438)
       by 0x41EE44: expand_item_list (util.c:1697)
       by 0x43CF1E: rsync_xal_get (xattrs.c:271)
       by 0x43D165: get_xattr (xattrs.c:315)
       by 0x4077A7: send_file_name (flist.c:1437)
       by 0x40826C: send_directory (flist.c:1678)
       by 0x408A80: send1extra (flist.c:1832)
       by 0x408E12: send_extra_file_list (flist.c:1904)
       by 0x417491: send_files (sender.c:184)
       by 0x421262: client_run (main.c:1039)
       by 0x421CF3: start_client (main.c:1287)


  - There is another unrelated leak at much lower rate; 
    109 bytes in 39 blocks are definitely lost in loss record 17 of 30
       at 0x4A05E46: malloc (vg_replace_malloc.c:195)
       by 0x41E05E: _new_array (util.c:1429)
       by 0x405305: recv_file_entry (flist.c:709)
       by 0x40A442: recv_file_list (flist.c:2362)
       by 0x42C9DD: read_msg_fd (io.c:376)
       by 0x42D269: wait_for_receiver (io.c:540)
       by 0x41434D: generate_files (generator.c:2345)
       by 0x420B63: do_recv (main.c:843)
       by 0x420F5C: do_server_recv (main.c:953)
       by 0x421057: start_server (main.c:983)
       by 0x420F9D: child_main (main.c:960)
       by 0x440167: local_child (pipe.c:156)
   Just FYI; not sure if you want to fix it.