Ruby: Refactor the object cache to better account for race conditions

[casperisfine]

Superseeds: #13054

The object cache is fundamentally subject to race conditions. Objects must be created before they are registered into the cache, so if two threads try to create the same object, we'll inevitably end up with two instances mapping to the same underlying memory.

To entirely prevent that we'd need a lot of extra locking which I don't think is really worth it compared to a few useless allocations.

Instead we can replace ObjectCache_Add by a getset type of operation, the extra instance is still created, but the later threads will receive the "canonical" instance and will be able to abandon their duplicated instance.

Additionally, this PR moves the ObjectCache implementation in Ruby, as it's much easier to debug there, and the performance difference is negligible. The ObjectCache instance is also exposed as Google::Protobuf::OBJECT_CACHE to better allow to debug potential memory issues.

cc @haberman @fowles

[haberman]

How do we validate that there is no performance regression?

I think the relevant benchmark would be something like:

msg = FooMessage()

# Read benchmark
msg.submsg = BarMessage()
1000000.times {
  msg.submsg
}

# Write benchmark
1000000.times {
  msg.submsg = BarMessage()
  msg.submsg
}

[casperisfine]

How do we validate that there is no performance regression?

So, note that there will necessarily be one. We're adding an extra method call on the fast path, and extra locking on the slow path.

That said I'm extremely unfamiliar with protobuf, and I never used it (it's a transitive dependency of various Google Cloud gems), so I'd appreciate if one of you could take this over, as it would be faster than doing back and forth. I mostly opened this PR as to show a proof of concept.

[fowles]

Casper, thanks for providing it! I will take this over.