add file type flag (symbolic link, regular file, directory)

In Sarracenia v02 (the protocol on which this work is based) there is a use case involving mirroring of trees of files. For that case to work, in addition to new versions of files being published, there is a need to publish events such as creation of symbolic links, and file removals as well.

In v02, the format uses the *sum* header to include that information. There are checksum algorithms called "L" (link), and "R" (remove) for these cases. the checksum values are just for
the file name and add little to no value. There is also a weakness in Sarracenia currently, where there is no event to post for directories/folder creation, and so the permissions of those items are not mirrored. Rather, default permissions are used to fill in this information.

for v03, the *sum* header is now called *integrity* in v03, and it may become overloaded in v03 because people want to use it to validate the origin of the post via a signature of some kind.
Currently in Sarracenia, v02 'L' is implemented as the v03 integrity method *link*, and v02 'R' is implemented as 'remove'. With this transliteration, it is likely difficult to have a signed removal or link event.

It would probably be good to:

* separate Link, remove and directory events from the *integrity* header.

It isn't clear if we need a unified way to represent all of them, or if some combination is OK.
The other problem with this is that thes are special cases for the signature algorithm anyways, which is why it was done this way in the first place. for a symbolic link, it does not make sense to checksum the file at the other end, because it might not point to the same data on both ends (depending on settings) so it needs to be a signature based on the link value itself.

Similarly, for directory, it makes no sense to digitally sign the directory, because that requires identical contents at the time of the check, and it is too dynamic for that to be worthwhile, and on different file systems the directory content will not be binary comparable anyways.

Similarly, for file 'removal', it is another special case, since the file data is not available to be checksumed.

In all these events, the meaning of the signature isn't so much to validate the content of the file, but more to

Option: lntegrity Header
-------------------------------

Leave it as in Sarracenia v02 version, the 'integrity' header includes *link*, and *remove*
algorithms, perhaps tweak the values to be more of a signature, rather than the current
SHA512 checksum based on the name. add a 'folder' method to fill the small gap.

Option: event header
----------------------------

one could add an *event* header, value is one of: 'modify' (file), 'folder' (directory creation), 'link', 'remove'. This would add the 'event' header to every message, about 12 bytes. It is the most obvious/clearest thing to do, but it adds bytes.

What happens to the *integrity* header in this case. It needs to *know* that these items are *special*

Option: Separate Headers
-----------------------------------

* Sarracenia already has a *link* header to store the value of the symbolic link. One could
use a 'link' header, whose value is where the link points to, and that one is taken care of.

* similarly, add a 'directory' header, to indicate the given file is a directory.

* similarly, add an 'remove' header to flag this event as a removal.

What happens to the *integrity* header in this case. It needs to *know* that these items are *special*

Any other ideas? suggestions?

No files, tests, or entry points are identified in the issue. Begin by locating the v03 header and integrity handling, then review how link, remove, directory, and regular-file events are represented; the work is done only after the event representation and its signing behavior are agreed and implemented.

Written by the indexing model from the issue text.