Cache worker metadata in worker bridge

[vigoo]

See #585 for measuring the effect

[afsalthaj]

More details;

ExecutionContext can be cached with component metadata mentioned in a binding of an API definition.

Note that API gateway or worker bridge can deal with multiple API Definiton IDs (pretty much multi tenancy) especially when it comes to cloud. This implies we will have loads to cache. Also, ARC is the best approach here. It's adaptive and take into consideration of situations where there is large gaps between accesses but it's accessed for sure at this time gaps. If we don't do this, the gateway users will feel the slowness whenever they hit their endpoint to invoke worker function at regular (but larger) intervals. ARC will be automatically LRU and size aware. Not sure how many Rust libraries have this support. But it's easy enough to implement (max 3 hours).

There should also be a function in worker service trait that accepts arguments (mainly useful for worker bridge) such that there is no need to look up function after loading component metadata again and again because that information is preloaded in evaluation-context of worker bridge. This will also avoid double (duplicate) parsing of function names when calling worker through worker bridge.

[afsalthaj]

Please find the explanations in PR and in slack: #630
and in here: https://zivergeteam.slack.com/archives/C057S2E4XT5/p1720013155994449

[afsalthaj]

As the next step, I did try to remove the download of metadata in Rib evaluation, however bumped or uncovered following bugs with the latest OSS release:

#638 (in progress)
#641 (under review)
#639 (not mandatory for now)