In FLE 1, users could declare a schema. This would tell the client what to encrypt and give the server a schema validator.
For FLE 2 the we still want a server-side schema but it is to be implicitly generated from the users encryption fields in their collection

1. CollectionImpl::parseValidator will generate a match expression in C++ code that mirrors the match expression that FLE 1 generates with a one difference
– InternalSchemaBinDataEncryptedTypeExpression or a new class like will be used instead that will disallow all FLE 1 types and FLE 2 client-side payloads
2. The match expression will be generated from the encryptFields information
3. The users match jsonSchema validator will be parsed with kEncryptKeywords OFF to prevent users from using FLE1.

A likely implementation is to first build a tree from a list of encryption fields and then serialize the tree to a match expressio ntree.

Example FLE1 JSON Schema:
The internal generated tree can be seen by running .explain()

print(tojson(db.foo.find ({
    $jsonSchema: {
        "type": "object",
        "properties": {
            "ssn": {
                "encrypt": {
                    "algorithm": "AEAD_AES_256_CBC_HMAC_SHA_512-Deterministic",
                    "keyId": [
                            UUID( "1362d0ed-6182-478e-bb8a-ebcc53b91aa1")
                    ],
                    "bsonType": "int"
                }
            },
            "user": {
                "type": "object",
                "properties": {
                    "account": {
                        "encrypt": {
                            "algorithm": "AEAD_AES_256_CBC_HMAC_SHA_512-Deterministic",
                            "keyId": [
                                    UUID("93282c77-9a6b-47cf-9c4c-beda02730881")
                            ],
                            "bsonType": "string"
                        }
                    }
                }
            }
        }
 }} ).explain()));