This reverts commit a31c2c10.

The commit reverted by this patch forces all autocommit SELECTs to open
a read view immediately, as a result they can't update tuple cache.
Turned out that one of our customers intensively uses such SELECTs, and
disabling cache for them results in performance degradation.

The reason why that commit was introduced in the first place was to
avoid read set bloating for big SELECTs (e.g. space.count()): currently
we track not only read interval boundaries, but also each tuple fetched
from the primary index if it is a secondary index that is being scanned.
However, it doesn't seem that we really need to do that - tracking an
interval read from a secondary index guarantees that if a tuple returned
by the iterator is modified the transaction will be aborted and so
there's no need to track individual tuples read from the primary index.

That said, let's revert this commit and instead remove point lookup
tracking in case it is a secondary index that is being scanned (done
later in the series).