Skip processLocalRelationshipUpdates when no relationships to write

[ZihanLi58]

handleRelationshipIngestion is called once per aspect during create/update. For aspects with no
RELATIONSHIP-typed fields, localRelationshipUpdates ends up empty after the existing .filter(entry -> !entry.getValue().isEmpty()) step. The existing code still calls
_localRelationshipWriterDAO.processLocalRelationshipUpdates with that empty list — its body is a no-op
for-loop, but the @Transactional annotation on the method opens + commits a transaction per call
regardless.

On a slow MySQL host this manifests as ~150 ms per aspect of pure transaction overhead (BEGIN + COMMIT
round-trips) for no useful work. With N aspects per create, total wasted time scales linearly.

Evidence

A 5-aspect MlModelInstance/create on prod-lor1 (a LinkedIn fabric) was observed at 867 ms wall-clock, of
which the actual SQL INSERT is 1-2 ms (per dao.benchmark.<entity>.create.aspects_5.latency). A wall-clock
async-profiler flame graph showed the rest of the time spent in:

BaseLocalDAO.create
→ createAspectsWithCallbacks
→ EbeanLocalDAO.createNewAssetWithAspects
→ handleRelationshipIngestion (called once per aspect)
→ EbeanLocalRelationshipWriterDAO.processLocalRelationshipUpdates [@transactional]
→ JdbcTransaction.commit → setAutoCommit → MySQL round-trip → __poll

Linear scaling confirmed by varying aspect count on the slow fabric:

Aspects	daoCreate (ms)
1	220
3	542
5	867

Per-aspect cost ≈ 162 ms regardless of whether the aspect actually has any relationships to write. None of
the test payloads contained any populated relationship fields, yet the cost still appeared linearly with N
aspects.

Fix

One-line short-circuit: skip the call to processLocalRelationshipUpdates when the list is empty, avoiding
the no-op @Transactional invocation entirely. Behavior is identical for the non-empty case (the existing
code path is unchanged for aspects that do have relationships to write).

Testing Done

• Compiles cleanly (./gradlew :dao-impl:ebean-dao:compileJava)
• Existing relationship-ingestion tests in EbeanLocalDAOTest cover the non-empty path; my change
  preserves identical behavior there. Local MariaDB4j-based test suite couldn't be run in my environment (test
  infra issue unrelated to the change), but the change is observably equivalent for the non-empty case and
  only avoids a no-op call in the empty case.
• Plan to verify end-to-end on prod-lor1 after pickup, expecting create latency to drop from ~600 ms to ~50
  ms for the same payload (matching prod-ltx1 baseline).

Checklist

• The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
• Links to related issues (if applicable)
• Docs related to the changes have been added/updated (if applicable)