Fix #5562 Improve HTTP Field cache allocation

[gregw]

Fix #5562 by initially putting cacheable fields into a inexpensive arraylist.
Only create the Trie (with space and complexity costs) if a second request is received.

Edit: the original PR only created the Trie on the second request, but that behaviour was removed in reviews. The cache is now created every request, even for non persistent requests.

[sbordet]

I'm not particularly fond of this change.

I am positive on delaying the creation of the Trie, until we know it's a HTTP/1.1 and we do have cache size > 0.

Seems to me that the chances for caching are the most common case by far, so I would skip the temporary list and go straight to the trie.

[sbordet]

@gregw also, I think we need some test -- something that verifies that the field is == in subsequent requests, etc.

[gregw]

@sbordet There are cache tests and they were broken until I fixed getFieldCache() to create the cache if needed. I think that method only really exists for the tests.

[gregw]

@lorban see the emptyTrie method I've added here. Also I wonder why the HttpField cache uses the Terniary Trie rather than just the array Trie.

I think this is one of the most important (if not THE important) case to optimise Tries for. We basically have the static and dynamic Tries... it is almost like HTTP/2 Hpack.
I wonder if we'd be better off with a specific cache class rather than generic Tries ?

[gregw]

@lorban nudge