Assign proper table oids when upgrading RelationMetadata

[jeeminso]

Summary of the changes / Why this improves CrateDB

Checklist

• Added an entry in the latest docs/appendices/release-notes/<x.y.0>.rst for user facing changes
• Updated documentation & sql_features table for user facing changes
• Touched code is covered by tests
• This does not contain breaking changes, or if it does:
  • It is released within a major release
  • It is recorded in the latest docs/appendices/release-notes/<x.y.0>.rst
  • It was marked as deprecated in an earlier release if possible
  • You've thought about the consequences and other components are adapted
    (E.g. AdminUI)

[jeeminso]

Adding a crate-qa test, crate/crate-qa#410.

[jeeminso]

This PR does fix the issue when I manually experiment with a 3 node cluster rolling upgrading each node from 6.2 to this branch - observed that the table oids do get assigned.

However, it does not logically make sense. With this PR, as the node restarts, the node reads the persisted local metadata and upgrades it to 6.3 then assigns/includes table oids to the metadata. These table oids are local to the node that cannot be serialized to the master node that could be 6.2. If another node goes through the same process, there are two set of local table oids created.

=> We must assign table oids when all nodes are upgraded.

[jeeminso]

The updated part in the PR is part of node start up logic executed before the node joins the cluster. Once it joins the cluster, the node receives ClusterChangedEvent(from master on 6.2) overriding the local clusterState as well as the locally assigned table oids -> table oids become 0. That is why this PR does not resolve the crate-qa test being added(crate/crate-qa#410).