obsmarker: add `date` as an explicit field The markers are now 5-item tuples (concluded by the date). The obsstore.fields contents have been updated accordingly. There is no change to the on-disk format yet, so the date has to be extracted every time we read binary markers and re-injected each team we write them. This introduces a slowdown that will be solved when a new version of the format is added. Such a slowdown was already introduced by the evolve extension anyway.

obsstore: add fields attribute to track each field in a marker We are going to increase the amount of data explicitly stored in obsolescence markers. This mean we are going to have a longer tuple and some values will be shuffled around. So we add a ``fields`` attribute to the obsstore class to keep track of what entry is what. This will be useful for extensions and for documentation purpose.

debugobsolete: explicitly display date in the output As the date is becoming a first-class citizen, we are displaying it in an explicit field. As a bonus it is now readable by humans.

obsolete: add a date argument to the `createmarkers` function The function is now just passing the value to create markers.

debugobsolete: use the new date argument on obsstore.create Now that we have this new argument, we can just use it.

obsstore: add an explicit `date` argument to obsstore.create The date will become an official field in the markers (and ultimately in the on-disk format). We start by making it an official argument for the function.

obsolete: explicitly pass metadata argument using keyword argument We are about to add more arguments to this function (date, parents, etc). Passing metadata as a keyword argument gives us more flexibility when adding them.

obsmarker: add a `flags` method We introduce a proper method to access the flag information.

test-treediscovery: update output after merge Recent change in the push process introduced an extra listing of the phase name space before the push (on default). Meanwhile on default, a fix introduced a new test with debug output. We update the test output to be correct.

revert: add an XXX about rename tracking We check for rename information in the dirstate. This is probably not enough to preserve this behavior when using an explicit target rev. I just spotted this while working on this code, but this is outside the scope of my series so I'm just adding a comment to highlight this suspicious situation.