[Do not review] Experimental sourcenode parser

[brendankowitz]

Description

Very experimental fhir parser.

Related issues

Addresses [issue #].

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)

To fix the issue, we should avoid accessing the virtual property Name in the constructor. Instead, we can introduce a private field to store the value of Name during construction and use this field to implement the Name property. This ensures that the constructor does not rely on virtual calls, eliminating the risk of unexpected behavior.

---

To fix the issue, we should avoid making a virtual call in the constructor. Instead of directly accessing the ResourceType property, we can use a private field to store the value during construction. This ensures that the constructor does not rely on virtual calls, eliminating the risk of unexpected behavior.

Steps to fix:

1. Introduce a private readonly field _resourceType to store the value of ResourceType during construction.
2. Modify the ResourceType property to return the value of _resourceType.
3. Update the constructor to assign the value to _resourceType instead of directly accessing the ResourceType property.

---

To fix the issue, we should avoid directly assigning the virtual property Location in the constructor. Instead, we can use a private field to store the value and expose it through the virtual property. This ensures that the virtual property is not accessed during the base class constructor execution, preventing any unintended behavior.

Steps to implement the fix:

1. Introduce a private field _location to store the value of Location.
2. Modify the Location property to return the value of _location.
3. Update the constructor to assign the value to _location instead of directly assigning to Location.

---

To fix the issue, we should avoid assigning a value to the virtual property Name directly in the constructor. Instead, we can introduce a private backing field for Name and use it internally within the constructor. The Name property can then return the value of this backing field. This ensures that no virtual calls are made during the constructor's execution.

---

To fix the issue, avoid accessing the virtual property Location directly in the constructor. Instead, use a private or protected field to store the value during construction, and then implement the Location property to return this field. This ensures that the constructor does not invoke any overridden implementations of the property.

Steps to fix:

1. Introduce a private or protected field _location to store the value of Location.
2. Update the constructor to assign the value to _location instead of directly to Location.
3. Modify the Location property to return the value of _location.

---

To fix the issue, we need to ensure that lastUpdated is never dereferenced when it is null. This can be achieved by adding a null check before accessing lastUpdated.Value. If lastUpdated is null, an appropriate fallback value (e.g., Clock.UtcNow) should be used.

The fix involves:

1. Adding a null check for lastUpdated before accessing lastUpdated.Value.
2. Ensuring that the fallback value is used if lastUpdated is null.

To fix the issue, we will simplify the Boolean expression _contentElement.Value.EnumerateObject().Any() == false to !_contentElement.Value.EnumerateObject().Any(). This change reduces unnecessary complexity while preserving the original logic. The fix will be applied directly to line 91 of the file.

---

To fix the issue, we will remove the redundant Select call from the LINQ query on line 210. The prop.EnumerateArray() method already returns an IEnumerable<JsonElement> that can be directly converted to an array using the ToArray() method. By removing the Select(x => x) call, we simplify the code without altering its behavior.

---

To fix the issue, the assignment to the variable definitions on line 170 should be removed entirely, as it is not used anywhere in the method. This will clean up the code and eliminate the unnecessary assignment. No additional changes are required, as the removal does not affect the functionality of the method.

---