[AA] Create `PackageMetadata` type

[miker83z]

After the validation of a package, if some functions were found using the #[authenticator] attribute, an immutable object can be automatically created. This object must be of type PackageMetadata:

public struct PackageMetadataV1 has key {
    // PackageMetadata (derived) id
    id: UID,
    // Package id
    package_id: ID,
    // Package version
    package_version: u64, //TODO check max num of versions and change u64 accordingly
    // Package name
    package_name: ascii::String,
    // Package modules
    module_handles: Vec<ascii::String>,
    /// Handles to external and internal functions.
    function_handles: Vec<FunctionHandle>,    
}

public struct FunctionHandle has copy, drop, store {
    /// The module that defines the function.
    module_handle: u16, // index of the module_handles vector  
    /// The name of the function.
    name: ascii::String,
    /// Flag for authenticator functions.
    is_authenticator: bool,
}

During the publishing/updating of a package including at least one #[authenticator] attribute, an immutable PackageMetadataV1 object is automatically created.

An AuthenticatorInfoV1 can be created using this function from PackageMetadataV1:

public fun create_auth_info_v1(
    self: &PackageMetadataV1,
    module_name: ascii::String,
    function_name: ascii::String,
): AuthenticatorInfoV1 {
    // Find module
    let module_handle = self.module_handles.find_index!(|m| m == module_name);
    assert!(module_handle.is_some(), EModuleNotFound);

    // Find function
    let function_handle = self.function_handles.find_index!(
      |f| 
      f.module_handle == *module_handle.borrow() 
      && f.name == function_name
      && f.is_authenticator
    );
    assert!(function_handle.is_some(), EFunctionNotFoundOrNotAuthenticator);    
    
    AuthenticatorInfoV1 { package: self.package_id(), module_name, function_name }
}

[valeriyr]

@miker83z @TheMrAI As it is mentioned in the following comment:
#8860 (comment)
We have authenticator versioning, so having only is_authenticator is not enough to define the AuthenticatorInfo version.
We need to consider adding information about the version somehow.

Have we decided to abandon the idea of ​​optimizing storage costs for accounts by holding the AuthenticatorInfo ID instead of a copy? As an option, we can create AuthenticatorInfo instances during publishing as discussed, and store something like the following struct as a dynamic field of an account:

public struct AuthenticatorInfoV1 has copy, drop, store {
    id: UID <-- needs to be added
    ...
}

// I expect this struct to be much more efficient than storing a copy in each account.
public struct AuthenticatorInfoV1Ref has copy, drop, store {
    authenticator_info_id: ID,
}

public fun ref(self: &AuthenticatorInfoV1): AuthenticatorInfoV1Ref {
    AuthenticatorInfoV1Ref{ authenticator_info_id: self.id}
}

Anyway, we can discuss this in a dedicated call.

[miker83z]

@valeriyr

@miker83z @TheMrAI As it is mentioned in the following comment: #8860 (comment) We have authenticator versioning, so having only is_authenticator is not enough to define the AuthenticatorInfo version. We need to consider adding information about the version somehow.

Right, it should be something like is_authenticator: Option<u8>.

Have we decided to abandon the idea of ​​optimizing storage costs for accounts by holding the AuthenticatorInfo ID instead of a copy? As an option, we can create AuthenticatorInfo instances during publishing as discussed, and store something like the following struct as a dynamic field of an account:

public struct AuthenticatorInfoV1 has copy, drop, store {
id: UID <-- needs to be added
...
}

// I expect this struct to be much more efficient than storing a copy in each account.
public struct AuthenticatorInfoV1Ref has copy, drop, store {
authenticator_info_id: ID,
}

public fun ref(self: &AuthenticatorInfoV1): AuthenticatorInfoV1Ref {
AuthenticatorInfoV1Ref{ authenticator_info_id: self.id}
}
Anyway, we can discuss this in a dedicated call.

In this case, optimizing storage costs reduces usability. We discussed about "how does a user knows which object id to pass to setup an authenticator?":

• Having an object id for each authenticate function would inevitably create the need to maintain a list of objects ids and associate them in some way to the original package (e.g., showing these in the explorer page of the package? Or in the gh repo?)
• Having a unique object id for each PackageMetadata associated to a specific package would make it a bit easier; moreover, the optimization of the derived id would make it straightforward for the user to start from a package and retrieve the data necessary to setup an authenticator.