feat: add tx kernel support for NoteAttachment

[PhilippGackstatter]

Introduces the NoteAttachment. Changes in Rust are complete, while tx kernel support is minimal, meaning all output notes are crated with a default None attachment.

This PR should be fine to review both in one go and by commit.

Main Changes

• Introduces NoteAttachment type in Rust.
• Updates NoteMetadata:
  • aux is replaced by attachment
  • execution_hint isn't useful for local notes (see also Refactor aux into NoteAttachment and simplify NoteTag #2109 (comment)), only for network notes. So it will move to the standardized network note attachment type (introduced in a later PR).
  • Technically NoteAttachment doesn't have to be part of NoteMetadata, but since the word-encoded metadata needs to contain the attachment type info, it is convenient.
    • Because of this, "note metadata" now refers to both the attachment and the actual note metadata (sender ID, tag, note type).
    • Because note attachments occupy at least a word on their own, there is no longer a Word to NoteMetadata conversion path.
    • But NoteMetadata can still be represented as a Word, including the note's metadata as well as attachment type info. This is called the metadata header. I found this new terminology reduces confusion when dealing with NOTE_METADATA_HEADER and NOTE_ATTACHMENT parameters in MASM. Both of them together form the note metadata, and the alternative of calling the header just NOTE_METADATA would be confusing, imo.
    • There is a NoteMetadataHeader type, but it is left private because it doesn't have to be public at this time.
      • It also includes decoding functionality which is also unused at this time. I implemented it but realized later it wasn't needed. It is tested for correctness regardless.
• Updates input_note_get_metadata and output_note_get_metadata kernel APIs to return both metadata header and attachment.
• This PR previously also removed aux and execution_hint parameters from output_note_create, but I decided to pull this out into a separate PR, so there is some temporary compatibility logic. So, eventually output_note::create will take just [tag, note_type, RECIPIENT].
• Updates how output_note_create builds the metadata header.
• Updates how input and output note commitments are built. The previous NOTE_METADATA is replaced by NOTE_METADATA_COMMITMENT which is hash(NOTE_METADATA_HEADER || NOTE_METADATA_ATTACHMENT).

Minor Changes

• Removes $kernel::memory::get_input_note_sender because it was unused and would have required an update.
• Replaces mem_stream hperm in output notes commitment with manual hashing, since the note metadata commitment must be computed first. We could maybe optimize this later by moving metadata commitment to memory and compute it when sealing a note (would require that all notes must be sealed at some point, which I would prefer anyway if we have sealing).
• NoteMetadata serialization can no longer reuse the word encoding because it must serialize the full attachment whereas the word encoding only serializes the attachment's commitment.
• Removes a bunch of NoteHeader encodings to felts that don't seem to be needed. These no longer work because metadata cannot be decoded from a word anymore.
• PartialNote is changed to contain a NoteHeader, so it can easily return &NoteHeader. Useful for OutputNote::header which would otherwise have to clone headers.
• Note conversions to NoteHeader are removed since it is no longer Copy.

Follow-Ups

The immediate follow-up to this PR is:

• Remove aux and execution_hint params from output_note::create.
• Add kernel API for setting an attachment on a note.
• Perhaps add APIs in miden::protocol for accessing attachment type, content type and attachment value in one go.
• Update protocol library markdown docs.

Later also:

• Introduce standard attachment for network accounts.
  • As part of this, move NoteExecutionHint to miden-standards.
• Possibly note sealing.

part of #2109

[bobbinth]

Looks good! Thank you! I left some comments inline - all of them pretty small.

[PhilippGackstatter]

After working with attachment_type and attachment_content_type in the subsequent PR, I ended up not liking these very much. I think they are too easily confused and don't capture their underlying concept very well.

• The attachment_type is user-defined and expresses the semantic meaning of the attachment, e.g. "represents the network account for which a network note is intended".
• The attachment_content_type expresses the protocol level encoding or format of the attachment.
  • I think a better alternative is NoteAttachmentRepresentation shortened to attachment_repr in code. I think this better captures that this value is about how the attachment is represented and says nothing about its content. I also like NoteAttachmentFormat and NoteAttachmentLayout to describe the "envelope" or representation of the attachment, rather than its content.

I don't have a great alternative for attachment_type yet. Something like NoteAttachmentPurpose or NoteAttachmentSemanticId sounds directionally right, but isn't fully convincing. NoteAttachmentContentType is actually also a reasonable alternative for NoteAttachmentType, since this actually identifies the type of the content. This is currently a misnomer and so could be repurposed.
Let me know if you have any ideas.

Edit: After thinking about it more, I think I would:

• Rename NoteAttachmentType to NoteAttachmentId, as a generic user-defined ID that identifies the content of an attachment, but not its representation.
• Rename NoteAttachmentContentType to NoteAttachmentFormat.

The rationale is that attachment_format is more likely to be interpreted as the shape in which the attachment comes rather than the content, similar to what "file format" describes for files. Additionally, attachment_id is unlikely to be interpreted as the shape of the attachment, but rather what it semantically represents.

"Attachment format" no longer aligns nicely with NoteAttachmentContent, but I think content_type blurs the lines too much and is worth renaming. We could go with NoteAttachmentContentFormat, but I think the content doesn't really make things clearer and attachment_id and attachment_format are nicer together without content.

I'd do this in a separate PR so we can find a consensus first, and avoid having to update a bunch of PRs that build on top of this one.

[bobbinth]

Overall, I agree with the sentiment - though, I think my preferences would be slightly different:

• NoteAttachmentContentType I would rename into NoteAttachmentKind - i.e., "what kind of an attachment it is".
• NoteAttachmentType I would rename into NoteAttachmentTemplate or NoteAttachmentScheme, but maybe NoteAttachmentId could also work.

[PhilippGackstatter]

Thanks for the input!

• NoteAttachmentKind - i.e., "what kind of an attachment it is".

This works for answering the question you mentioned, but could also be mistaken for "what kind of standardized attachment is it?". Though, format could be argued to have the same problem. So, since I can't come up with anything more precise than kind or format, I think we can go with either. I'll use "kind", unless there are other opinions.

For NoteAttachmentType, we could also make things more concrete and use NoteAttachmentStandard. This would work quite well in the context of standardized attachments:

impl NetworkAccountTarget {
    /// The standardized type of [`NetworkAccountTarget`] attachments.
    pub const ATTACHMENT_STANDARD: NoteAttachmentStandard = NoteAttachmentStandard::new(1u32);
}

When there is no established standard, users can either make up their "own standard" or use NoteAttachmentStandard::custom which is the previous NoteAttachmentType::untyped (value 0).

It does make attachment_standard more "opinionated" in the sense that we expect every attachment to specify what standard it follows (or just say "custom"). It matches how we would like attachments to be used and it is harder to confuse with "attachment kind" than some other alternatives. The downside is that it's a bit awkward to use when users don't follow a standard, but maybe that's fine.

Edit: NoteAttachmentStandard doesn't work either. If a user creates a non-standard NoteAttachmentStandard(42) the name automatically suggests it is standardized, but it's not. We do actually need something like "type" that can represent a range of identifiers, and only a subset of those is actually standardized.
In the absence of other opinions, will go with NoteAttachmentKind and NoteAttachmentScheme.

[bobbinth]

Looks good! Thank you!