let us later throw away the renegotiated content due to a name mismatch.

We do not need to update the ->name field just before writing the headers as
the computed ->name on open and create is sufficient.  Updating ->name here is
essentially a no-op - except in the case of Vary where the key has internally
changed (to account for the Vary prefix), but the original name has not.
However, writing the Vary'd-accounted key means that when we read the cache
next that we will error out and disregard the just renegotiated response and
fetch the content all over again - oops!

(This is largely a case where I think we may have overthought ourselves; hence
the explanation is here in the commit rather than in the file itself.)

* modules/cache/mod_disk_cache.c
  (store_headers): The originally opened ->name is sufficient.
* CHANGES: Combined with r538992, note that renegotiation for Vary's seem to
  work far better.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@538997 13f79535-47bb-0310-9956-ffa450edef68