fix: allow using non-lowercased custom levels

[chernodub]

The code failed to use useLevel when the custom level was, for example, camel-cased.

I updated the test to reflect this occasional scenario and removed the unnecessary transformation of the log level.

[chernodub]

If needed, I could duplicate the test for the lowercase scenario too. I'm assuming here that both cases are covered by this test now.

[jsumners]

I don't understand what issue this is solving. With the current code, fooBar is equivalent to foobar.

[jsumners]

The purpose here is to compare names in a consistent manner.

[chernodub]

Hi @jsumners, thanks for the response!

My reasoning for the change:

1. Before the change, validLogLevels contained values that are not mapped to lowercased values, so the check would always fail for non-lowercased values. (like infoCustom example above).
2. We could potentially prepare the validLogLevels by mapping each value to lowercase, so the check will result to true. After that, the getValidLogLevel will return a lowercased value, and the code of pino-http will try calling something like logger.infocustom which will also throw (because the valid call would be logger.infoCustom)

Pls let me know what you think, thanks

[mcollina]

lgtm

[mcollina]

I think this is ok!

...