Vague problem statement:

To better support of retracting schema (as part of the timelines work, see #783), we need to have more knowledge than is currently available in-memory. Mentat's definition of a schema attribute currently does not allow us to determine if a particular schema attribute is actually present in the datoms, or if it's a derived default value.

E.g. if we did not assert [:db/add 100 :db/index true], then the index field in the Attribute struct for entid=100 will be false. From the point of view of schema retraction, meaning of that false value is not the same as if actually asserted that [:db/add 100 :db/index false].

• Schema retraction rule 1) If :db/ident is being retracted, and that entity is a schema attribute - that is, it also has :db/valueType and :db/cardinality - these datoms (and any optional ones) must also be retracted. (why leave around dangling schema attributes?)
• Schema retraction rule 2) if either of the required schema attribute entities are being retracted (:db/valueType, :db/cardinality), then all of the required schema attributes must be retracted, as well as a corresponding :db/ident.

However, currently we can't tell by just inspecting an AttributeMap that a given entity has these attributes. And so to enforce rule 1, we must read datoms from disk.

Implementation of schema retraction introduced in #783 punts on rule 1, and only enforces rule 2.