Bug 5322: Do not leak HttpReply when checking http_reply_access (#1764)

Bug 5322: Do not leak HttpReply when checking http_reply_access (#1764)

... as well as response_delay_pool and send_hit directives.

    auto check = clientAclChecklistCreate(...); // sets check->reply
    check->reply = reply; // self-assignment does nothing
    HTTPMSGLOCK(check->reply); // an unwanted/extra lock

When ACLFilledChecklist::reply is already set to X, resetting it to X
should not change HttpReply lock count, but some manual locking code did
not check that "already set" precondition and over-locked reply objects
set to ClientHttpRequest::al::reply by clientAclChecklistFill().

Current known leaks were probably introduced in 2021 commit e227da8 that
started supplying HttpReply to ACLChecklist in clientAclChecklistFill().
The added code locked the reply object correctly, but it was
incompatible with unconditional manual locks in three existing indirect
clientAclChecklistFill() callers (calling clientAclChecklistCreate()).

This change removes all known similar leaks and improves
ACLFilledChecklist API to prevent future similar leaks.