Optimize TableId cache performance

[milleruntime]

The TableId class uses a guava cache for all accesses to table ID and it currently uses weakValues(). According to the Guava javadoc, weakValues are poor for caching and softValues should be considered instead. It would be good to compare the performance of the two to see which is better. Since a cluster with high table turnover may see different performance than one that maintains the same set of tables, we may want to make this configurable/pluggable.

[ctubbsii]

SoftReferences are cleaned up at the discretion of the Garbage Collector. They are kept around longer, which is better for caching, because it is more likely you'll get a cache hit. However, that's not how we're using this cache. We're using WeakReferences, specifically because we're only using it for deduplication/canonicalization, and not cache hit performance. The javadoc for WeakReference says "Weak references are most often used to implement canonicalizing mappings.", which is how we are using it. The javadoc for SoftReference says "Soft references are most often used to implement memory-sensitive caches.", which is not how we are using it.

I think what we have is correct. Also, this is a slight internal optimization so we don't have a ton of internal objects referring to the same table id (canonicalization for storage optimization), essentially the same as String interning. It is not something that is cached for performance/speed, as it is not speed-critical code, and I certainly don't think it would be worth making pluggable.

[milleruntime]

OK sounds good.

[milleruntime]

It is probably worth mentioning this in the code since there are no comments about the cacheing in the class.

[ctubbsii]

I will add some comments.

[ctubbsii]

Added comments in #1782