Catalog Entry

Made the internals of CatalogEntry private and added getters/setters for the Child/Parent relation, fixing a bug in the process.

CatalogSet

CatalogSet used to contain an extra level of indirection between the mapping of name to CatalogEntry.
This was necessary because of the logic surrounding renames.

This PR cleans up that logic, a rename now starts a new chain of versions under the new name and is fully transactional.
A rename will now result in a RENAMED_ENTRY being added to the end of the old name’s chain.
The new chain will add a RENAMED_ENTRY before adding the new entry to the new name’s chain.

Because of this we can now simplify this connection to just the mapping of (case insensitive)name to CatalogEntry (version chain).

As a result of this:
The MappingValue class has been removed
The EntryValue class has been removed
The EntryIndex class has been removed
The EntryDropper class has been removed

CatalogEntryMap

This class manages the entry chains, it provides methods to update, add, remove and get entries.
The CatalogSet contains a catalog entry map.

DependencyManager

The DependencyManager was not transaction-aware, this resulted in having to grab a lock in the CatalogSet before making changes to the dependency manager.
Then inside the DependencyManager we needed to call private methods of the CatalogSet that assumed a lock was already held.

We now store the dependency connections in CatalogSets, making them transaction aware.

DependencyEntry

Added a DependencyEntry abstract class.

The entry initiating the dependency:

struct DependencyDependent {
    CatalogEntryInfo entry;
    DependencyDependentFlags flags;
};

The entry targetted by the dependency:

struct DependencySubject {
    CatalogEntryInfo entry;
    DependencySubjectFlags flags;
};

The internals of these are identical, except for:
The name of the CatalogEntry, the sides are switched in the DependencyReliant/DependencySubject for lookup purposes.
Overloaded virtual methods:

• EntryInfo, this corresponds to the right side of the mangled name
• EntryMangledName, this corresponds to the right side of the mangled name
• SourceInfo, this corresponds to the left side of the mangled name
• SourceMangledName, this corresponds to the left side of the mangled name

CREATE SEQUENCE seq;
CREATE TABLE tbl (i integer default nextval('seq'));

tbl relies on the existence of seq to continue existing.
If we attempt to drop seq while tbl is still alive, it will result in an error, unless CASCADE is provided, in that case tbl is silently dropped along with seq.

This creates two DependencyCatalogEntry's:
Dependent:
seq -> tbl

'tbl' is a Dependent of 'seq'

Dependency:
tbl -> seq

'seq' is a Dependency of 'tbl'

DependencyCatalogEntry names follow this format:
MangledEntryName\0MangledEntryName
MangledEntryName follows this format:
type\0schema\0name

Example for a dependency from Table main.tbl on Sequence not_main.seq:

Table\0main\0tbl\0Sequence\0not_main\0seq

To abstract this prefixing logic away we use a DependencyCatalogSet, this acts like a wrapper around a CatalogSet, adding the prefix to every interaction (get/remove/create)

Earlier on in development these were actual CatalogSets, but that led to discovering that our Catalog design is not built for nested CatalogSets.