flagprocessors: move _flagserrorclass attribute on revlog & co This is a small duplication, and the last bit we need to get rid of the mixin. Honestly, I am not fan of that class attribute and it mostly exist to accomodate The simple-storage whose usage of flag processors is dumbious and that is currently dead code anyway. However I don't want to be pulled into futher unrelated cleaning so it is a small price to pay. Differential Revision: https://phab.mercurial-scm.org/D6822

flagprocessors: directly duplicate the deprecated layer back into revlog The code duplication benign and will get removed in a couple of month anyway. Differential Revision: https://phab.mercurial-scm.org/D6821

flagprocessors: make `processflagsraw` a module level function One more steps toward removing the mixin. Differential Revision: https://phab.mercurial-scm.org/D6820

flagprocessors: make `processflagsread` a module level function One more steps toward removing the mixin. Differential Revision: https://phab.mercurial-scm.org/D6819

flagprocessors: make `processflagswrite` a module level function One more step towards removing the mixin. Differential Revision: https://phab.mercurial-scm.org/D6818

flagprocessors: make `_processflagsfunc` a module level function This is the first step toward removing the flag processing mixin. Differential Revision: https://phab.mercurial-scm.org/D6817

flagprocessors: writetransform function take side data as parameter (API) If we want some flag processors to be able to store sidedata it needs to be actually fed that data. Differential Revision: https://phab.mercurial-scm.org/D6816

flagprocessors: add a `sidedata` parameters to _processflagswrite To read sidedata using flagprocessors, we need flag processors to store them. So we pass this information to the flag processing layer. Differential Revision: https://phab.mercurial-scm.org/D6815

revlog: add a `sidedata` parameters to addrevision If we want to eventually store sidedata we need to be able to pass them along. Differential Revision: https://phab.mercurial-scm.org/D6814

flagprocessors: have the read transform function return side data (API) This makes it possible for flag processors to -read- flag data. Differential Revision: https://phab.mercurial-scm.org/D6813

flagprocessors: return flagdata in the main processing function This function input and return are becoming stranger and stranger bnut I don't have a good plan to make is saner without problematic code duplication, so it will be this way to now. Differential Revision: https://phab.mercurial-scm.org/D6812

flagprocessors: return sidedata map in `_processflagsread` Right now, flag processors does not return sidedata, by they will. So, we prepare the caller to receive it. Differential Revision: https://phab.mercurial-scm.org/D6811

revlog: use the new sidedata map return in the sidedata method So far things, seems logical. Differential Revision: https://phab.mercurial-scm.org/D6810

revlog: return sidedata map from `_revisiondata` Nothing extra any side data yet. However, it will happens in the future. So we better prepare the callers of the `_revisiondata` to deal with it. Differential Revision: https://phab.mercurial-scm.org/D6809

revlog: introduce a `sidedata` method The method give access to extra information related to the revision. Such data will not be part of the hash be strongly related to the revision. Having them stored at the revlog level helps the storage consistency story and simplify various things. Example of data we could store there: - copy tracing related informations - graph structure related information (useful for discovery) - unresolved conflict data The full implementation will be introduced gradually in the coming changesets. Differential Revision: https://phab.mercurial-scm.org/D6808