…stence stack

Remove the EntityCacheEntry wrapper since the timestamp fields were never used anyways;
instead the underlying Caffeine cache transparently handles access times, and the
types of entries we cache are simply the existing ResolvedPolarisEntity.

Remove interactions of business logic with explicit "cache entries", instead
operating on ResolvedPolarisEntity. Fix the equals()/hashCode() behavior of
PolarisEntity to be compatible with PolarisBaseEntity as intended.

Improve code comments to explain the (current) relationship between PolarisEntity
and PolarisBaseEntity, and clarify the behaviors in Resolver.java.

Fully remove the PolarisRemoteCache interface and its methods. Add different
methods that aren't cache-specific instead.

…erize ResolverTest

… of CallContext

This appeared to be some leaky divergence that occurred after CallContext had been
removed, but PolarisMetaStoreSession really is only a low-level implementation detail
that should never be handled by BasePolarisCatalog/FileIOFactory.

This plumbs CallContext explicitly into the FileIOFactory and FileIOUtil methods and
thus removes a large source of CallContext.getCurrentContext calls; now the threadlocal
doesn't have to be set at all in BasePolarisCatalogTest.

…ence-poc

Extract a basic abstract base class BaseMetaStoreManager which can
hold shared logic between implementations of PolarisMetaStoreManager

…g to implement UNDROP

but for now are entirely unused. We can reintroduce it with a better design against multiple
backends when/if we want to implement UNDROP.

…toreSession;

only leave the transaction-specific methods in PolarisMetaStoreSession

…ence-poc-extract-abstract-base

…ransactional-style

PolarisMetaStoreSession, so that BasePersistence properly exposes a lookupEntityByName
method where impls that use secondary indexes can easily just lookup an entity by name
instead of doing two lookups.

…tityActive

protected-visibility; remove all callsites where PolarisMetaStoreManagerImpl
calls it. Technically, while in the same package this doesn't prevent
it from leaking, but we could reposition PolarisMetaStoreSession into
a separate transaction-specific package to help protect it from leaking
the lower-level abstractions.

…nd add

writeEntity method to BasePersistence, with a default impl in PolarisMetaStoreSession
containing what was previously in PolarisMetaStoreManagerImpl. This now protects
all writes in PolarisMetaStoreManagerImpl from dealing with the three-table
implementation detail. Technically slightly changes the ordering of updates
within a transaction for renameEntity, but is arguably a more correct ordering,
and the ordering doesn't interleave reads anyways.

…ap behavior

from the underlying BasePersistence.

Pushdown all the deleteFromEntities* methods into PolarisMetaStoreSession and
add deleteEntity to BasePersistence which encapsulates handling the separate slices.

…nto a new

IntegrationPersistence interface; these methods encapsulate certain type-specific
behaviors that are indirectly tied to persistence entities, such as principal
secrets, storage integrations, etc.

…ameLookupRecord,

remove unused method

…nto a new package "transactional".