Duende.Bff.Yarp: inconsistent parsing of Yarp route metadata in v3.0.0

[ripebananas]

Hey, after upgrading to Duende.Bff.Yarp v.3.0.0, I noticed that the Yarp route metadata is parsed a bit inconsistently (version 2.3.0 does not have this issue).
Consider the following metadata that works as expected in version 2.3.0 (notice the config has true value, and not "true"):

...
"Metadata": {
    "Duende.Bff.Yarp.OptionalUserToken": true,
    "Duende.Bff.Yarp.AntiforgeryCheck": true
}
...

The Duende.Bff.Yarp.OptionalUserToken does not seem to work anymore, because OptionalUserToken is parsed like this in AccessTokenRequestTransform.cs:

...
return new BffRemoteApiEndpointMetadata()
{
    OptionalUserToken = yarp.Config.Metadata?.GetValueOrDefault(Constants.Yarp.OptionalUserTokenMetadata) == "true", // <-- issue here, yarp.Config.Metadata?.GetValueOrDefault(Constants.Yarp.OptionalUserTokenMetadata) returns "True"
    RequiredTokenType = requiredTokenType
};
...

As opposed to this, 'Duende.Bff.Yarp.AntiforgeryCheck` is parsed more robustly in AntiforgeryMiddleware.cs:

...
if (route.Config.Metadata.TryGetValue(Constants.Yarp.AntiforgeryCheckMetadata, out var value))
{
    if (string.Equals(value, true.ToString(), StringComparison.OrdinalIgnoreCase)) // <-- no issue here
    {
        if (!context.CheckAntiForgeryHeader(_options))
        {
            context.Response.StatusCode = 401;
            _logger.AntiForgeryValidationFailed(route.Config.RouteId);

            return;
        }
    }
}
...

Needless to say, after updating the Yarp route metadata as "Duende.Bff.Yarp.OptionalUserToken": "true", the issue is gone, but this seems like a small breaking change to me, thanks.

[RolandGuijt]

Thanks for reporting this! Much appreciated.
I've created an issue for our BFF team so this can be improved.