Fix a segfault in code produced by Visual Studio 2019

[ironage]

The segfault was discovered by additional tests enabled in #4706.

It looks to have been introduced by #4178 to fix another MSVC issue in debug mode. Instead of reverting that change which would bring up the old debug mode issue, this changes the code to not rely on the mpark::visit(overload pattern with an auto case as this seems to be a combination of code that shows a bug in MSVC 2019 and/or mpark.

I have observed that there are other ways to "fix" the issue, such as removing the lifetime extension idea and adding an explicit case for GlobalKey:

    auto get = overload{
        [this](InternString str) -> PrimaryKey {
            return get_string(str);
        },
        [](const GlobalKey& key) -> PrimaryKey {
            return key;
        },
        [](auto otherwise) -> PrimaryKey {
            return otherwise;
        },
    };
    return mpark::visit(get, key);

But the changes in this PR seem less magical and less prone to similar issues in the future.
This should also fix #4624

☑️ ToDos

• 📝 Changelog update
• 🚦 Tests (or not relevant)

[nirinchev]

Should this revert #4749 and fix it in a similar way?

[ironage]

@nirinchev yes good point, I would rather have verbose code like this and reenable the runtime checks in debug mode - in case there is another bug lurking there as well. However, I will wait for one reviewer to approve the initial fix before propagating it elsewhere.

[jedelbo]

I like the more explicit approach.

[ironage]

I removed the auto&& cases from the visitor pattern which VS 2019 doesn't seem to like. This has a couple of other benefits as well: the compiler will produce an error if we forget to handle a type instead of getting swallowed by the auto case, and also gives us slightly more specific error messages.

[jedelbo]

Why don't we use std::move(callback) here.

[jedelbo]

I think we should use the same pattern everywhere. Any particular reason not to have a callback variable here?

[jedelbo]

Same as above

[ironage]

This was the only case where VS 2019 actually didn't work with std::move, and I've added a comment about it and changed the rest to be consistent.

[jedelbo]

std::move?