Upgrade db to compile with v145 by default

[ccptoebeans]

Configuration Changes

• Changed windows kotlin configuration to build with MSVC v145 by default.
• Removed dependency pin for old protobuf version (blue no longer requires the version pin)
• Changed cmake presets to use v145 by default.
• Updated versions of microsoft/vcpkg & carbonengine/vcpkg-registry submodules to latest

Code Changes

• returning an int 0 from a PyObject* type function is now a compilation error, these have been replaced with nullptr returns.
• typedefs have been replaced with using, however this was just a matter of taste, using X = Y is more modern, and easier to read (in my humble opinion 🙇) than typedef Y X
• db was using an old stdext class hash_set this has been removed from the latest version of the MSVC toolchain, and so needed to be replaced. It's been replaced with a standard unordered_set.
• Replacing hash_set with unordered_set required exposing the hash function for InternalStoreElement, so that it could be used in functor templates struct std::hash<WStringStoreElement>, std::hash<ByteStoreElement> & std::hash<StringStoreElement>.

Note

There seems to be a bug, both in the old & new versions of the code, where if you try to insert a >64 bytes string into the store that has an identical first 64 bytes as a different string already inside the string store, the store will treat it as an identical string, and the string store will not store both strings. This may not be a bug if DB stringStore does not support strings longer than 64 bytes. If for say the store is only responsible for column names for example🤷.

This requires more investigation, but this v145 upgrade work does not affect this bug

[CCP-Aporia]

Thanks, this looks good to me!

Note

There seems to be a bug, both in the old & new versions of the code, where if you try to insert a >64 bytes string into the store that has an identical first 64 bytes as a different string already inside the string store, the store will treat it as an identical string, and the string store will not store both strings. This may not be a bug if DB stringStore does not support strings longer than 64 bytes. If for say the store is only responsible for column names for example🤷.

I don't think there is a bug. The hash function only decides which bucket an element should be inserted into, not whether an element already exists in the set. As per cppreference.com:

Internally, the elements are not sorted in any particular order, but organized into buckets. Which bucket an element is placed into depends entirely on the hash of its value. This allows fast access to individual elements, since once a hash is computed, it refers to the exact bucket the element is placed into.