Investigate changes in SERVER-54046: Permit empty objects as expressions in $set and $addFields aggregation stages

$addFields and $set will no longer throw an error if you want to set a path to an empty object.
For example the stage {$set: {a: {}}} would take an incoming document and set the 'a' field to an empty object.
The behavior of $project behavior has not been changed and in order to get the same behavior a user would still have to wrap the object with $literal like this: {$project: {a: {$literal: {}}}}

Description of Linked Ticket

Permit empty objects as expressions in $set  and $addFields aggregation stages. For example, an aggregation stage definition

 {$set: {a: {}}} 

should be accepted and should add field "a: {}" to the resulting object (this looks like an intuitively expected system behavior). Nesting of objects should be supported, like in a following example: 

{$set: {a: {b: {}}}}

 Currently, to achieve this behavior a wrapper expression $literal has to be used like this:

{$set: {a: {$literal: {}}}}

But an aggregation stage definition 

{$set: {a: []}} 

is accepted and results in field "a: []", which is somewhat inconsistent with handling of empty objects.

$set update operator expression with a field with an empty object  

db.foo.updateOne({}, {$set: { a: {} }})

is accepted.

Furthermore, we have recently relaxed restrictions for update modifiers (SERVER-38909) and $addFields (SERVER-48890)(permits {$set: {}}) to permit empty documents, thus this improvement would increase consistency.

Currently, execution of a $set aggregation stage with an empty object as an expression, like 

db.foo.updateOne({}, [{$set: { a: {} }}])

fails with the following error message: "Invalid $set :: caused by :: an empty object is not a valid value. Found empty object at path a".