[server][dvc] Open store before bootstrapping from blob transfer.

[jingy-li]

Summary

Open the store before bootstrapping from blob transfer, otherwise the offset record and StorageVersionState can not update successfully.

How was this PR tested?

Run at 2 dvc hosts.

1. The first host successfully bootstraps from Kafka, because there is no any available hosts, and successfully generate snapshot.
   
2. The second host successfully bootstraps from blob transfer, and without snapshot, because snapshot will generate when it is ingested from Kafka.
   

Does this PR introduce any user-facing changes?

• No. You can skip the rest of this section.
• Yes. Make sure to explain your proposed changes and call out the behavior change.

[gaojieliu]

@FelixGV
I saw you modified this interface to pass svsSupplier in the past:
#44

For the usage in this class, it is a little confusing:

Supplier<StoreVersionState> svsSupplier = () -> storageMetadataService.getStoreVersionState(storeVersion);
    syncStoreVersionConfig(storeAndVersion.getFirst(), storeConfig);

    Runnable runnable = () -> {
      AbstractStorageEngine storageEngine =
          storageService.openStoreForNewPartition(storeConfig, partition, svsSupplier);

So it first looks up SVS state from the metadata partition and then pass it to StorageService#openStoreForNewPartition, I wondered whether it is necessary to use this pattern as internally if versionStateCache is null in the get path, it will try to do the lookup internally.

My main question is that whether this param: svsSupplier is necessary or not in openStore and openStoreForNewPartition.

[gaojieliu]

I guess the user can pass a null supplier for such usage, right?

[gaojieliu]

Code change itself looks good and I left an open-question to @FelixGV .