Undo trunk r13270: "Refactor Vector and Stack to STL counterparts"
to avoid stability issues related to std::vector migration.
Undo trunk r13269: "Vector refactor: move almost all clients to std::vector"
to avoid stability issues related to std::vector migration.
Undo trunk r13266: "vector-refactor branch: align Vector API with std::vector"
to avoid stability issues related to std::vector migration.
Make sure Squid dumps core and not just promises one
when memory management goes wrong.
Avoid "FATAL: Squid has attempted to read data from memory that is not present"
crashes. Improve related code.

Shared memory caching code was not checking whether the response is generally
cachable and, hence, tried to store responses that Squid already refused to
cache (e.g., release-requested entries). The shared memory cache should also
check that the response is contiguous because the disk store may not check
that (e.g., when disk caching id disabled).

The problem was exacerbated by the broken entry dump code accompanying the
FATAL message. The Splay tree iterator is evidently not iterating a portion of
the tree. I added a visitor pattern code to work around that, but did not try
to fix the Splay iterator iterator itself because, in part, the whole iterator
design felt inappropriate (storing and flattening the tree before iterating
it?) for its intended purpose. I could not check quickly enough where the
broken iterator is used besides mem_hdr::debugDump() so more bugs like this
are possible.

Optimized StoreEntry::checkCachable() a little and removed wrong TODO comment:
Disk-only mayStartSwapOut() should not accumulate "general" cachability checks
which are used by RAM caches as well.

Added more mem_hdr debugging and polished method descriptions.

Fixed NullStoreEntry::mayStartSwapout() spelling/case. It should override
StoreEntry::mayStartSwapOut().
Report IpcIo file name with errors and warnings
to inform admin which cache_dir needs troubleshooting or tuning.

Some level-0/1 messages did not mention disker ID or file name at all while
others relied on disker process ID which is too low-level information from most
admins point of view.

Also improved error and warning messages consistency.
Lifted 16777216 slot limit from rock cache_dirs and shared memory caches.
Also fixed rock disk space waste warning.

Rock store and shared memory cache code used entry and slot limit as if
the two were the same. In large caches, the number of entry slots may exceed
the number of entries supported by Squid (16777216 entries per store). This
is especially likely with large caches storing large entries (many slots
per entry with maximum number of entries) or large caches using small slot
sizes.

AFAICT, the bug led to the "tail" of cache storage being unused and cache
entries being purged even though there was still space to store them. Also,
Squid was allocating smaller shared memory tables (and temporary cache index
build tables) than actually needed for the configured cache sizes.

Note that this change does not remove the per-store 16777216 entry limit.


The old [small] rock warning about wasted disk space assumed that a cache
entry occupies exactly one slot. The updated warnings do not.


Also fixed and simplified db scanning condition during cache index build.
Significantly reduced Large Rock (and slightly shared memory) RAM requirements
by not allocating 40 (and 12) bytes of unused RAM per cache slot.

Rock: Stale code inherited from the Small Rock implementation allocated 40
bytes of unused memory per rock db slot (2.5GB of RAM for a 1TB disk with 16KB
db slots). The current (Large Rock) code stores the same kind of information
(and more) in a different location (Ipc::StoreMap).

Shared memory: Similarly, the Large Rock-based shared memory cache allocated
12 bytes of unused memory per shared memory cache slot (3.8MB of RAM for a
10GB shared RAM cache with 32KB slots).
Restored Squid ability to cache (in memory) when no disk caches are configured
which was lost during r12662 "Bug 3686: cache_dir max-size default fails"

The bug was hidden until the memory cache code started calling
StoreEntry::checkCachable() in branch r13315, exposing the entry size check to
a broken limit.


r12662 converted store_maxobjsize from a sometimes present disk-only limit to
an always set Squid-global limit. However, store_maxobjsize value was only
calculated when parsing cache_dirs. A config without cache_dirs would leave
store_maxobjsize at -1, triggering "StoreEntry::checkCachable: NO: too big"
prohibition for all responses.

This change moves store_maxobjsize calculation from parser to storeConfigure()
where some other Store globals are computed after squid.conf parsing. 

Also honored memory cache size limit (just in case cache_mem is smaller than
maximum_object_size_in_memory) and removed leftover checks for
store_maxobjsize being set (it should always be set, at least to zero).
Allow HITs on entries backed by a shared memory cache only.

A typo in r12501.1.59 "Do not become a store_client for entries that are not
backed by Store" prevented such entries from being used for HITs and possibly
even purged them from the memory cache.
Stop wasting 96 RAM bytes per slot for high-offset slots in large shared caches
with more than 16777216 slots.

Ipc::StoreMap was using the same structure for all db slots. However, slots at
offsets exceeding SwapFilenMax (16777215) could not contain store entry
anchors and the anchor part of the structure was wasting RAM for those slots.
This change splits a single array of StoreMapSlots into two arrays, one
storing StoreMapAnchors and one storing StoreMapSlices. The anchors array is
shorter for caches with more than 16777216 slots.

For example, a StoreMap for a 1TB shared cache with default 16KB slot sizes
(67108864 slots) occupied about 6.5GB of RAM. After this change, the same
information is stored in about 2.0GB because unused anchors are not stored.

32-bit environments were wasting 72 (instead of 96) bytes per high-offset slot.


Also simplified Ipc::StoreMap API by removing its StoreMapWithExtras part.
The added complexity caused bugs and was not worth saving a few extra lines of
callers code. With the StoreMap storage array split in two, the extras may
belong to each part (although the current code only adds extras to slices),
further complicating the WithExtras part of the StoreMap API. These extras
are now stored in dedicated shared memory segments (*_ex.shm).

Added Ipc::Mem::Segment::Name() function to standardize segment name
formation.  TODO: Attempt to convert shm_new/old API to use SBuf instead of
char* to simplify callers, most of which have to form Segment IDs by
concatenating strings.
Fix malloc corruption from use-after-free in peer_select.cc

same as trunk r13340
Document counter-intuitive round-robin cache_dir selection bias; decrease it.

Many squid.confs have at least two groups of cache_dir lines. For example,
rare "large" objects go to larger/slower HDDs while popular "small" objects go
to smaller/fast SSDs:

    # HDDs
    cache_dir rock /hdd1 ... min-size=large
    cache_dir rock /hdd2 ... min-size=large
    cache_dir rock /hdd3 ... min-size=large
    # SSDs
    cache_dir rock /ssd1 ... max-size=large-1
    cache_dir rock /ssd2 ... max-size=large-1
    cache_dir rock /ssd3 ... max-size=large-1
    # rock store does not support least-load yet
    store_dir_select_algorithm round-robin

Since round-robin selects the first suitable disk during a sequential scan,
the probability of /hdd1 (/ssd1) selection is higher than other HDDs (SSDs).
Consider a large object that needs an HDD: /hdd1 is selected whenever scan
starts at /ssd1, /ssd2, /ssd3, and /hdd1 while /hdd2 is selected only when the
scan starts at /hdd2 itself! Documentation now warns against the above
cache_dir configuration approach and suggests to interleave cache_dirs:

    cache_dir rock /hdd1 ... min-size=large
    cache_dir rock /ssd1 ... max-size=large-1
    cache_dir rock /hdd2 ... min-size=large
    cache_dir rock /ssd2 ... max-size=large-1
    cache_dir rock /hdd3 ... min-size=large
    cache_dir rock /ssd3 ... max-size=large-1
    store_dir_select_algorithm round-robin

Squid's historic implementation of round-robin made its natural bias even
worse because it made the starting point of the sequential scan to be the last
selected dir. In the first configuration example above, it boosted the
probability that the scan will start at one of the SSDs because smaller
objects are more popular and, hence, their dirs are selected more often.  With
the starting point usually at an SSD, even more _large_ objects were sent to
/hdd1 compared to other HDDs! The code change avoids this artificial boost
(but the cache_dir lines should still be interleaved to avoid the natural
round-robin bias discussed earlier).
Fixed typo breaking accounting of [forgotten] entries during index build.

Forgotten entries would still contribute to the total entry count and, hence,
result in some entries being evicted from cache prematurely.

Added in "Stop wasting 96 RAM bytes per slot" revision (branch r13321).
Polished to address squid-dev review comments.
Avoid store_client.cc "entry->swap_filen > -1 || entry->swappingOut()" asserts.

A client may hit on an incomplete shared memory cache entry. Such entry is
fully backed by the shared memory cache, but the copy of its data in local RAM
may be trimmed. When that trimMemory() happens, StoreEntry::storeClientType()
assumes DISK_CLIENT due to positive inmem_lo, and the store_client constructor
asserts upon discovering that there is no disk backing.

To improve shared cache effectiveness for "being cached" entries, we need to
prevent local memory trimming while the shared cache entry is being filled
(possibly by another worker, so this is far from trivial!) or, better, stop
using the local memory for entries feeding off the shared memory cache. The
latter would also require revising DISK_CLIENT designation to include entries
backed by a shared memory cache.
Cross-compile: Add BUILDCXX and BUILDCXXFLAGS configure options

We have provided HOSTCXX for some time. However in the official cross
compilation terminology HOST is the output architecture. Renames to
BUILD to align with the official terminology of which machine the tools
it builds are run on.

Also, add a flags variable and document these as important variables in
./configure --help output
Update the Comm:: API for read(2)

... using an algorithm suggested by Alex Rousskov.

The code for Comm:: read operations is shuffled into comm/libcomm.la and
the files comm/Read.{h,cc} in symmetry with the current Comm::Write API.


The new API consists of:

 * Comm::Read() which accepts the Comm::Connection pointer for the
socket to read on and an AsyncCall callback to be run when read is
ready. The Job is responsible for separately initiating read(2) or
alternative action when that callback is run.

 * Comm::ReadNow() which accepts an SBuf buffer and a CommIoCbParams
initialized to contain the Comm::Connection pointer for the socket to
read on. TheCommIoCbParams will be filled out with result flag, xerrno,
and size.
This synchronously performs read(2) operations to append bytes to the
provided buffer. It returns a comm_err_t flag for use in determining how
to handle the results and signalling one of OK, INPROGRESS, ERROR, EOF
as having happened.

comm_read() API is retained for backward compatibility during the
transitional period. However it is now deprecated and scheduled for
removal ASAP. The SBuf overloaded variant is now removed.


 * Comm::ReadCancel() - a renaming of the comm_read_cancel() AsyncCall
API. Other cancel API(s) are now deprecated and will be removed ASAP.

Code using comm_read_cancel() with AsyncCall may immediately switch to
this new API with no logic changes necessary even if they are not using
other new Comm API calls.


 * Comm::MonitorsRead() - a renaming of comm_monitors_read() AsyncCall
API. comm_monitors_read() is now removed.



Other changes:
 - the unused comm_has_pending_read_callback() API is erased.
 - the IoCallback::buf2 mechanism previously used for SBuf read I/O is
   erased.
 - ConnStateData is converted to this new API for filling its SBuf I/O
   buffer and for monitoring pinned connection closures.
 - fde::readPending() converted to new Comm::MonitorsRead() API.
 - Comm half-closed monitoring feature is also converted to this new API.

NP: one bug in ConnStateData handling of intercepted HTTPS traffic is
noted but not fixed in this patch.
Cleanup: remove comm_read_cancel(AsyncCall) API

Converting remaining users of the old API wrapper to Comm::ReadCancel.
Fix typo in rev.13441