Chore: Use mapping of custom attributes to AYON attributes

[iLLiCiTiT]

Changelog Description

Change custom attributes sync to allow custom mapping of AYON attribute to ftrack custom attributes.

Additional review information

PR is changing how ftrack custom attributes sync works. Instead of one-to-one mapping there is a option to map AYON attribute to different ftrack attribute. Because of technical difficulties it was decided that it is possible to map one AYON attribute to one hierarchical attribute, or multiple standard attributes (with different names).

There is a checkbox that does allow to use previous one-to-one mapping, but is not based on ayon group anymore.

Mandatory custom attributes (ayon id/path, auto sync and sync failed) are automatically created automatically during sync/prepare project if don't exist yet, these are the only one which stay in ayon group.

Create/Update custom attributes work same way as before, but does not add ayon group to them.

Removed library_project, applications and tools_env custom attributes. Library checkbox can be change in AYON FE so it is not necessary to set it in ftrack.

Conversion of settings from older ftrack addon versions will change the overrides automatically to use "old style" sync. Default settings should be set to match ftrack default custom attributes (This might still need some investigation, I didn't spend time to find out what built-in ftrack custom attributes have available).

Possible issues

When ayon+settings://ftrack/custom_attributes/attributes_mapping/enabled or ayon+settings://ftrack/custom_attributes/attributes_mapping/mapping changes it is necessary to trigger sync of project to "propagate" the change -> it is hard to capture that correctly. Future enhancement.

Testing notes:

1. Create package, upload to server and use in bundle.
2. When converting settings from older version, you should see that custom attributes settings is overriden too.

Custom attributes sync - Backwards compatibility

1. When ayon+settings://ftrack/custom_attributes/attributes_mapping/enabled is set to False all should work as before.
2. It is possible to have set to True and map all AYON attributes in ayon+settings://ftrack/custom_attributes/attributes_mapping/mapping to hierarchical custom attribute in ftrack with same name. The custom attributes must be on ftrack server -> e.g. if Create/Update custom attributes action was triggered at least once on the server.
3. When converting settings from older ftrack addon version, step 1 and 2 happens automatically (is set to false, and mapping is set 1to1.

Custom attributes sync - Using mapping

1. Set ayon+settings://ftrack/custom_attributes/attributes_mapping/enabled to True.
2. Set mapping of AYON attributes to ftrack custom attributes in ayon+settings://ftrack/custom_attributes/attributes_mapping/mapping. For example map frameStart to fstart and frameEnd to fend.
3. Sync of project should sync those values.
4. Auto-sync should from that moment sync them too.
5. Sync from AYON to ftrack should also propagate the changes correctly.
6. All attributes without mapping, or without mapped attribute name will ignore any changes.
7. Editorial publishing, which is creating new hierarchical entities does set the attributes correctly too.

Creation of mandatory custom attributes

There are ftrack custom attributes that are mandatory for AYON sync ("ayon_id", "ayon_path", "ayon_sync_failed" and "auto_sync_enabled"). Those are now created automatically if do not exist. That happens automatically during Prepare project or Sync to AYON action. So it is not necessary to run Create/Update custom attributes action at all for simple sync.

1. If ftrack server already has one of the custom attributes, rename them (to e.g. ayon_id2).
2. Run Prepare project or Sync to AYON action.
3. The custom attribute is created, or a message is shown that used ftrack API key does not have permissions to do so.
4. Don't forget to remove new ayon_id and rename ayon_id2 back to ayon_id when finished testing.

Resolves #157

[MilaKudr]

Copying settings only works from a some previous versions, not generally.

[iLLiCiTiT]

Copying settings only works from a some previous versions, not generally.

Found out it cannot be fixed in addon, it is caused by server logic which skipes settings override application if source version does not have any overrides. It should change in next release, but even without it, it should be ok for production use-cases.