Feat/resource removal

[SupremaLex]

Potential implementation of removal of resource feature

[SupremaLex]

@ilionic can you review this pr?

[HashWarlock]

This could use some rework. I do not think there should be a need for PendingResourceRemovals. Instead there could be an added bool property to the ResourceInfo trait named pending_removal which is false by default.

if an account requests to remove_resource and the sender is not the root_owner then you can do:

Resources::<T>::try_mutate_exists(
		(collection_id, nft_id, resource_id.clone()),
		|resource| -> DispatchResult {
			if let Some(res) = resource {
				res.pending_removal = true;
			}
			Ok(())
		},
	)?;

remove from Resource if it is the root_owner that calls remove_resource

Then for accept_removal you can check if the pending_removal property is set to true in the Resources StorageNMap and remove the resource_id.

[HashWarlock]

Also, based on the RMRK 2.0.0 spec ACCEPT if a resource is accepted in the past it is not possible to remove the resource in the future. The accept resource history is something that would need to be tracked in this case.

Removal of resources

It is not possible to remove resources accepted in the past. This prevents art rug-pulls.

[SupremaLex]

Regarding the RMRK spec, Bruno said that resource removal wouldn't be added to the spec, but it is ok to add this feature to EVM&Substrate versions.

[HashWarlock]

Just one question about if the Resource ID key would be removed from the StorageNMap. Then small suggestion for checking if a Resource StorageNMap contains_key() for the error checks. Other than that, I think it is good.

[HashWarlock]

Looks good from my view.