DecompressedSize added to Resource table

[rajithaalurims]

Description

A new nullable column DecompressedSize added to Resource table.
A new table type is created to support backward and forward compatibility.
Stored procedures are changed to use data from either old or new data type depending on schema version supported on the instance.

Related issues

Addresses [issue #156583].

Testing

Describe how this change was tested.

FHIR Team Checklist

• Update the title of the PR to be succinct and less than 65 characters
• Add a milestone to the PR for the sprint that it is merged (i.e. add S47)
• Tag the PR with the type of update: Bug, Build, Dependencies, Enhancement, New-Feature or Documentation
• Tag the PR with Open source, Azure API for FHIR (CosmosDB or common code) or Azure Healthcare APIs (SQL or common code) to specify where this change is intended to be released.
• Tag the PR with Schema Version backward compatible or Schema Version backward incompatible or Schema Version unchanged if this adds or updates Sql script which is/is not backward compatible with the code.
• When changing or adding behavior, if your code modifies the system design or changes design assumptions, please create and include an ADR.
• CI is green before merge
• Review squash-merge requirements

Semver Change (docs)

Patch|Skip|Feature|Breaking (reason)

[SergeyGaluzo]

@rajithaalurims I think this PR is a prerequisite to address issue https://microsofthealth.visualstudio.com/Health/_workitems/edit/156583

[SergeyGaluzo]

Lower case

[rbans96]

nit: Can we rename the entries to FHIR_TotalDataSizeInGB and FHIR_TotalIndexSizeInGB

[rajithaalurims]

Done

[rbans96]

I assume we would emit failure logs from the background job. Would we need to setup any alerting/monitoring if the background job fails?
Do you think if its useful to add a section for alerts/monitors if needed at all for this design spec.

[rajithaalurims]

Great question. I have added alerting and monitoring in the ADR I put in place on WP side. If there are no metrics being emitted as expected we do get ICMs.

[rbans96]

I understand this is nullable for backward compatibility. Do we have a test coverage to ensure we don't pass the null value/0 value for these changes, if it makes sense?

[rajithaalurims]

For iteration1 null and 0 are acceptable. After iteration 2, null values are not acceptable. Once all three iterations are done, we should not have any null values in that table. I can add test coverage in iteration 2 or 3 to make sure there are no null values.