Initialize mMetaData correctly, fix ref count

mMetaData was inconsistently initialized to either a MetaData or
MetaDataBase object. The former resulted in the destruction of
a RefBase object without ever incrementing its reference count.
This is normally very brittle, since the accidental creation of
an sp<> results in duplicate deallocation. Hence we are starting
to diagnose it. In this case it appears to just add extra overhead.

Since mRefCount can be concurrently accessed, declare it as atomic.
This is a minimal fix, which can be improved further. Local and remote
reference counts are currently still read with inconsistent memory
orders. Since the results appear to only be trusted when they
guarantee that there is no concurrent access (as they should be),
memory_order_relaxed on loads seems sufficient. Generally reference
count increments can also be relaxed, while decrements should be
acq_rel to ensure that all accesses to the object become effective
before deallocation. I believe that's correct here as well. Since
I'm unfamiliar with the code, I made only essential changes.

Bug: 79265389

Test: Built and booted master.
Merged-In: I3cb65e9f880588abdb0712890e7a654311577b07
Change-Id: I3cb65e9f880588abdb0712890e7a654311577b07
(cherry picked from commit b421f6ea)