Bug: dbCreated is false when db already exists

[tanjinx]

Description

dbCreated is set to false even when db already exists, which results in that tablet start always try to creeate the db. (credit to @vmogilev )

Related Issue(s)

Checklist

• "Backport to:" labels have been added if this change should be back-ported
• Tests were added or are not required
• Did the new or modified tests pass consistently locally and on the CI
• Documentation was added or is not required

Deployment Notes

[tanjinx]

Many test failures are related to InitShardPrimary:

0110 19:59:45.466702   20051 vtctlclient_process.go:213] Executing vtctlclient with command: vtctlclient --server localhost:16006 InitShardPrimary -- --force --wait_replicas_timeout 31s ks/0 zone1-4410 (attempt 1 of 10)
E0110 20:00:16.571859   20051 vtctlclient_process.go:58] error in InitShardPrimary output W0110 19:59:45.478667   22809 main.go:96] W0110 19:59:45.478483 server.go:2439] primary-elect tablet zone1-0000004410 is not the shard primary, proceeding anyway as -force was used
W0110 19:59:45.478703   22809 main.go:96] W0110 19:59:45.478525 server.go:2445] primary-elect tablet zone1-0000004410 is not a primary in the shard, proceeding anyway as -force was used
InitShardPrimary Error: rpc error: code = Unknown desc = tablet zone1-0000004411 InitReplica failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded;tablet zone1-0000004412 InitReplica failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded
E0110 20:00:16.570499   22809 main.go:105] remote error: rpc error: code = Unknown desc = tablet zone1-0000004411 InitReplica failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded;tablet zone1-0000004412 InitReplica failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded
, err exit status 1

so looks like the fix has some side effect
however, I deployed a build with this change and tried InitShardPrimary or PRS, neither of them failed,

[tanjinx]

as we found out the root cause of the long reparenting time was not caused by this bug, and upstream filed an issue for this vitessio#17521. Going to close this one.