Log SubCode and Severity for RocksDB erros.

[yao-xiao-github]

Example
trace.127.0.0.1.4503.1630440279.a5Q2jo.0.1.xml:<Event Severity="40" ErrorKind="Unset" Time="1630440291.196540" DateTime="2021-08-31T20:04:51Z" Type="RocksDBError" ID="0000000000000000" Error="IO error: No space left on device" Method="Commit" RocksDBSeverity="0" SubCode="4" ThreadID="16869869807533468410" Backtrace="addr2line -e fdbserver.debug -p -C -f -i 0x2becf2c 0x2bec0f0 0x2bec4d1 0xf29787 0xf2b7e2 0x2b68d46 0x2b6a285 0x7fb2598fbea5" Machine="127.0.0.1:4503" LogGroup="default" Roles="CC,CP,DD,GP,MS,RK,RV,SS,TL" />

Code-Reviewer Section

The general guidelines can be found here.

Please check each of the following things and check all boxes before accepting a PR.

• The PR has a description, explaining both the problem and the solution.
• The description mentions which forms of testing were done and the testing seems reasonable.
• Every function/class/actor that was touched is reasonably well documented.

For Release-Branches

If this PR is made against a release-branch, please also check the following:

• This change/bugfix is a cherry-pick from the next younger branch (younger release-branch or master if this is the youngest branch)
• There is a good reason why this PR needs to go into a release branch and this reason is documented (either in the description above or in a linked GitHub issue)

[foundationdb-ci]

AWS CodeBuild CI Report

• CodeBuild project: foundationdb-pull-request-build
• Commit ID: 67cf33f
• Result: FAILED
• Build Logs (available for 30 days)

[yao-xiao-github]

Rebase to clear format errors.

[foundationdb-ci]

AWS CodeBuild CI Report

• CodeBuild project: foundationdb-pull-request-build-macos
• Commit ID: 15017bc
• Result: SUCCEEDED
• Build Logs (available for 30 days)

[foundationdb-ci]

AWS CodeBuild CI Report

• CodeBuild project: foundationdb-pull-request-build
• Commit ID: 15017bc
• Result: FAILED
• Build Logs (available for 30 days)

[xumengpanda]

LGTM for the initial version.

SevError will put the process to a bad state.
If rocksDB has a recoverable error AND FDB decides to wait for RocksDB to recover instead of replicate it, we should output SevWarning instead of SevError

[yao-xiao-github]

LGTM for the initial version.

SevError will put the process to a bad state.
If rocksDB has a recoverable error AND FDB decides to wait for RocksDB to recover instead of replicate it, we should output SevWarning instead of SevError

Ack. We will need to decide the log level based on the severity.