feat: immutibility and contracts that allow document history

[QuantumExplorer]

Contracts now should allow the following four fields:
keepsHistory: keep the history of all previous versions of the contract. Default False
readonly: is the contract readonly? If it is it can never be changed. Default False
documentsKeepHistoryContractDefault: should contract documents keep history by default? Default False
documentsMutableContractDefault: should contract documents be mutable by default? Default True

Document Types also have two new fields:
documentsKeepHistory: should contract documents keep history? Overrides contract default at the document type level.
documentsMutable: should contract documents be mutable? Overrides contract default at the document type level.

Querying documents at a block level is now also allowed. However for now just one document by its Id can be queried.
The query looks like this:

        "where": [
            ["$id", "==", "6A8SGgdmj2NtWCYoYDPDpbsYkq2MCbgi6Lx4ALLfF179"]
        ],
        "blockTime": 300
    }```

[shumkov]

@QuantumExplorer We planned to use a special JSON Schema readOnly keyword to enable immutability and actually it does nothing at the storage level. It's about validation logic which is in DPP at the moment.

As I understood there are four different changes in this PR:

1. Proper update document
2. Querying block time (no idea about this feature at all)
3. Immutability (which is currently must be implemented in DPP) and using special JSON Schema keyword
4. Document history (revisions)

Could you please split them into different PRs according to our contributing guide?

[QuantumExplorer]

@shumkov Are you aware that this splitting will take me quite some time. Since this has not been released to production I don't see the benefit of value/time. We need to stop with the approach of everything needs to be perfect all the time or velocity will be reduced.

Regarding some comments:

2. This is about the ability to query previous revisions. Right now you can only query as an equality. Query with "in" values should be possible but would need an update to GroveDB.

3. Immutability (Nothing is stopping you from using both). I believe this secondary index database should be able to have immutability on its own merits.

[shumkov]

@QuantumExplorer If the project is not in production it doesn't mean that our contributing guide is not valid anymore (and other best practices). I don't see why this functionality is so urgent that we should merge it with breaking our rules.

2. I see. Thank you. I need to go to the code and I probably will have more questions.

3. Hm... I thought it's Drive repo, so you want to incorporate some functionality to Drive which won't be used?

[QuantumExplorer]

@shumkov My point is that before production, and with very important time constraints, we could bend the contributing guide. As a compromise could we merge this one in, but in the future I'll be sure to make my PRs more single feature focused?

3. Well I don't see why you wouldn't use it, but if you want to do the validation on a more expensive level then I'm not going to care for now. All I want is that this functionality exists.

[shumkov]

@QuantumExplorer Sounds good to me!

3. Do you mind using a special keyword for immutability https://json-schema.org/draft/2019-09/json-schema-validation.html#rfc.section.9.4?

[shumkov]

👍