* Add back the sequential template generation.
* Add additional matter test case.
* Add a unit test for one of the latest poorly-performing matter templates.

This reverts commit dc9997e2.

* check if temperature is a signed type

Feature Map Attribute conformance and enablement as per the Device type features per endpoint (#1300)

- Creating the feature table and populating it with data from the xml
- Creating the data_type_feature table which references to data type cluster and feature ids. Populating it the same way as the data type attributes and data type commands. For now only adding those features which are of mandatory conformance for now.
- Adding selectDeviceTypeFeaturesByEndpointTypeIdAndClusterId to extract the features per endpoint type and cluster for setting the featureMap attribute appropriately.
- Using the above function from query-config#insertOrUpdateAttributeState to update the featureMap attribute accordingly when its value is 0.
- Start reporting featureMap attribute value warnings for each endpoint based on device type conformance
- Adding unit tests for the device type cluster compliance for feature map attribute

- Adding features in cluster xml as a bitmap such that bitmap name='feature' can be removed from the xml in favor of features which holds the featuremap information as well as defines the feature bitmap such that there is no duplicate information between features and bitmap name=feature

- Showing the correct UI based on category from json files when there is only one zcl and template package and user does not have any packages to select from.

- Making sure the same named feature codes which exist on different bits of the cluster are handled correctly
- Updating the zap schema as per the new changes
- JIRA: ZAPP-1346

This reverts commit 61d328ca.

Fixing Custom XML issues:
- Cleaning up the custom xml UI update as well as the custom xml package uploading such that there are no duplicates
- Fixing the custom xml UI for attributes, commands and events when cluster extensions are added through custom xml. Needed the custom xml package ids to be included
- Fixing the duplicate attributes and commands which show up in the attribute and command UI when a custom cluster with custom attributes and commands is added. This is solved by using a set in : reduceAndConcatenateZclEntity(db, id, [...new Set([...standAlonePackageIds, clusterInfo.packageRef])],
- Adding unique constraint to Attribute table and adding insert or replace to attribute insert query such that custom cluster extensions are not reloaded into the db.
- Making sure the global attributes are part of the custom clusters in static-zcl.js while calling reduceAndConcatenateZclEntity
- Making sure that session partition numbering is correct for the partitionNumber column
- For loading custom cluster extensions such as attributes and commands. Making sure they are loaded into the database based on the top level zcl package loaded. This is needed for sdk upgrades or custom xml in multi-protocol. See changes to zcl-loader-silabs and zcl-loader
- When adding custom xml, there are instances where multiple zcl packages are loaded for the same xml file. This was an issue with the mutation observer. Getting the load new package call out of the observer to fix this. Reproducer: Open zap, add custom xml from extensions, close extensions pane, add another xml from extensions and you will see two instances of the xml added. If you add another xml then you see 3 instances. This is fixed in ZclCustomZclView.vue
- Making sure that the delete button appears across custom xml for removal and doing some minor UI cleanup
- Add more unit tests for custom xml
- Cleaning up zap toolbar UI for logos
- JIRA: ZAPP-1351

* Revert "Fixing the theme based on the zcl package chosen (#1295)"

This reverts commit 5cc76149.

* Revert "Using getAllSessionPartitionInfoForSession instead of getSessionPartitionInfo for more stability (#1294)"

This reverts commit c9ca9f71.

* Revert "Fixing the ZAP GUI for blank configurations and opening category based configurations (#1289)"

This reverts commit fba76592.

* Revert "ZAP: Multi-protocol Configurator Integration (#1276)"

This reverts commit 06d14282.

> - Schema changes such that sessions now have session partitions to allow multiple zcl and template config files.
> - Session packages and endpoint types are now linked to a session partition such that generation and UI can be made exclusive to the device type selected on an endpoint
> - All relevant queries have been updated with session partition
> - imp-exp of .zap files is taken into account here as well
> - ZAP Generation can now generate the corresponding templates based on the category of the device type and the category of the generation templates eg: matter or zigbee. The same goes for UI
> - All existing tests pass with these changes
- Fixing the cluster view when multiple zcl device types are selected
- ZAP: Opening existing .zap files does not allow multi-device type selection
- Fixing sessionAttempt in initialize.js and cleaning up the packages from the session in jsonDataLoader function in import-json fixed this
- Other minor cleanup
- Fixing CMP generation for command line in startup.js#generateSingleFile such that it generates for all generation template json files and not just one of them
- bumping the feature level of zap
- Adding the reference to parentEndpointRef in endpoint extended in db-mapping due to rebase and also fixing the selectAllEndpointsBasedOnTemplateCategory for the same
- Cleaning up session package and session partitions to avoid having the wrong session packages and partitions in deleteAllSessionPackages
- Cleaning up query-session#ensureBlankSession
- Fixing the zap schema for command trigger warnings when adding endpoints
- Fixing the parent-endpoint.test.js just like the rest with session partition info
- Fixing the default attribute enablement based on catgeory such as matter/zigbee for global attributes
other minor cleanup
- Not showing the extensions tab in case of multi-protocol since it is currently not supported, see ZCLToolbar.vue
- Showing all logos based on the categories from the zcl files selected, see ZCLToolbar.vue
- Added multi-protocol tests, see multi-protocol.test.js, multi-protocol.zap, test-utils.js
- Removed lo-devices.xml from the zcl-with-extensions.json matter file to test multi-protocol more efficiently since for generation as is the case in reality as well.
- Fixing calls to insertEndpointType with device type params in query.test.js
- Fix cypress tests for vue tour which was happening due to category(zigbee/matter) not being picked from zcl properties files. Also handling the default use case when category is not found
- Calling this..dispatch('zap/updateClusters') in vue tour after update to endpoint type due to multi-protocol changes
- Fixing the default use case for showing and not showing UI elements in ui-options.js
- Fixing server-bare.test.js when inserting a package along with some other minor cleanup which is needed
- Fix the server-bare.test.js
- Improving the session creation and package selection process in the UI via ZapConfig.vue changes
- Pre-selecting the package files which exist in ZapConfig.vue. Also now showing package selection view if the packages which exist in the db are the same as the ones in the .zap file.
- Showing a warning in the custom xml page when a multi-proptocol config is open since custom xml is not currently supported for custom xml. See ZclCustomZclView.vue
- JIRA: ZAPP-1216

* fixing helper to have a NULL placeholder and adding tests

Also fixes endpoint-config codegen for the device type array: These are 32-bit
values, not 16-bit.

* Fixing endpoint type command table schema

- incoming and outgoing used to be in the endpoint_type_command table as a single record. However this is an association that is related to the command source and the cluster side. When the cluster side is the same as the command source then it is an outgoing command. If the cluster side and command source are not the same then it is an incoming command. Now we have 2 entries instead of 1 in the endpoint_type_command based on this logic.
- The above allows us to implement the enabled only .zap file correctly or else we lose the incoming commands when the .zap file is saved for the enabled only content since the way the commands were stored before this commit is that the client sourced commands were stored in the client side cluster and the server sourced command is stored in the server cluster which was wrong.
- Updating the endpoint_type_command queries based on the schema changes to the table
- Fixing the import/export for the above schema changes
- Updating the UI code to capture the new schema correctly
- In the insert command for ENDPOINT_TYPE_COMMAND table in query-impexp.js there is an ignore because the .zap files have been hand edited where there are multiple references of the same command in it.
- Adding generation tests for the enabled only file format
- Updating the default zap file format version to 2
- JIRA: ZAPP-1113

- Support multiple device type with array input

- Enabling multiple zcl device types per endpoint

- Unify array usage for DeviceType and DeviceIndentifier

- Updating updateEndpoint and duplicateEndpoint based on the schema change with the introduction of Endpoint_type_device table

- Updating import/export endpoint type apis to handle multiple zcl device types per endpoint

- Updating selectAllEndpointTypes and selectEndpointType such that they update the multiple zcl device types correctly

- Add primary device type selection logic

- Add multi device type modification warning dialog

- Generalize the warning message

- Maintain specific device type ref name, device type code and device type profile id per endpoint for backwards compatibility

- Removing the warning dialog and making sure the the zcl device types per endpoint are updated correctly

- Making sure that the device type clusters are added when an endpoint is edited and a new zcl device type is added to the endpoint

- When loading the old zap files and editing the endpoint the selected devices do not show up in the device UI. Updating deviceIdentifier with this.zclDeviceTypes[deviceTypeRefs[i]].code fixed it

- Add device type identifier and device type revision to endpoint_type_device junction table instead of keeping it in endpoint table such that multiple zcl device types can be added per endpoint. Schema change lead to the rest of the changes in queries for endpoint_type, endpoint_type_device and endpoint tables along with UI changes to vue files, actions and mutations.

- Add multi version option to endpoint card

- Updating device version and device identifier to be in endpoint type instead of endpoint just like device type ref

- Updating db-mapping to have device version and identifier in endpoint_type
- Fixing query-config#updateEndpointType to add the entries properly to endpoint_type and endpoint_type_device tables
- Use endpoint_type_device table in a bunch of queries instead of endpoint_type to get references to device version and identifier
- Fix import isc with the new schema
- Fix edit and update endpoint by fixing httpPatchEndpointType with respect to device version and identifier
- Fix Create endpoint UI and endpoint card such that device identifier and device version can be updated properly through the UI
- Fixing actions and mutations for device version and identifier for an endpoint type such that UI and backend are in sync
- Updating state.js such that device version and identifier are in endpoint type instead of endpoint now

- Fix import issues with the new schema for multiple zcl device types and device version/identifier

- Fixing import and export of .zap files such that saving and re-opening of zap files continues to give the right results when multiple zcl device types are chosen

- Update Cypress tests to support multi device types

- Adding tests for adding multiple zcl device types per endpoint. The tests include adding a new endpoint and editing an existing endpoint

Make device select show selected item at edit mode

- Updating endpoint_fixed_device_type_array helper such that it can include the endpoint identifier as well
- Including isEndpointIncluded such that endpoint_fixed_device_type_array can add the endpoint id as well
- Adding generation tests for endpoint_fixed_device_type_array's update

- Fixing the import of old zap files for device identifier/code, version and profile id.
- Making sure device identifier/code, version and profile id are imported correctly when importing the .zap files
- Fixing the matter workflow which is running into some issues by seperating each of the arguments
- Fixing user_endpoints helper such that endpoints have an associated reference to the device versions and device identifiers

- Fixing helper-endpointconfig.js for endpoint_fixed_device_type_array, endpoint_fixed_device_type_array_offsets and endpoint_fixed_device_type_array_lengths
- The device list is now properly populated with the deviceId, deviceVersion and endpoint Id associated with the device
- Fixing the query-endpoint.js query
- Fixing the device Id test since they are now part of endpoint type instead of endpoint
- Fixing endpoint_fixed_device_type_array_offsets and endpoint_fixed_device_type_array_lengths in helper-endpointconfig.js
- Adding tests for multiple zcl device types per endpoint and addition device type helpers
- Adding a endpointTypeDevice db mapping
- added a query in query-device-type.js to retrieve device type information based on endpoint type id
- Created a helper to iterate over the device types. This can be used within user_endpoints and user_endpoint_types
- Adding testing for the multiple zcl device types per endpoint generation by adding an additional .zap file, modifying the endpoint config template to test new helpers and added tests in gen-matter-4.test.js

- Reverting this change such that the zigbee regen diff check does not break because of this

- Cleaning up user_endpoints such that it is not an async function because turning it into an async currently breaks the after template generation for eg:user_endpoints > after (See zap-event template in zigbee)
Github: ZAP#862

Co-authored-by: Gergely Kiss <gergely.kiss@silabs.com>

- Add zcl_struct_items_by_struct_and_cluster_name helper for retrieving struct items based on struct and cluster name in helper-zcl.js
- Updating selectAllStructItemsByStructName to handle cluster name as well
- Updating the xml for TargetStruct such that it is now present in binding and access control clusters
- Adding a test to make sure the right struct items are generated based on cluster names
- Github: ZAP#916

Adding to enabled_attributes_for_cluster_and_side and zcl_attributes_server helper to replace chip_server_cluster_attributes (#899)

- chip_server_cluster_attributes is returning server attributes which are not actually enabled because the server side cluster is disabled.
- The reason chip_server_cluster_attributes is picking the server side attributes which are not enabled is because those are enabled in the .zap file(Which is the case for saving user selections and ease of use). However the helper is not actually checking if the cluster is enabled as well.
- enabled_attributes_for_cluster_and_side is solving this issue correctly and actually only showing attributes which are truly enabled.
- Extending endpointTypeAttributeExtended such that there is a common place for an attribute map
- Updating endpointTypeAttributeExtended with everything that attributeExportMapping had such that it can act as a common place for all other temporary maps that have been created across our code. Also sorting endpointTypeAttributeExtended for easier readability and avoiding duplicate keys
- Updating zcl_attributes_server block helper such that it can behave like chip_server_cluster_attributes.
- Updating attribute map such that it can be used more widely
- Adding additional helpers to remove the stateful helpers
- Adding removeKeys option for removing certain columns which are not needed in a block helper such as enabled_attributes_for_cluster_and_side and zcl_attributes_server
- Adding if_unsupported_attribute_type and if_attribute_complex to check for unsupported and complex zcl data types
- Deprecating old stateful helpers with new stateless helpers
- Adding select data type using type name and cluster id to data_types, enums, bitmap,  numbers and structs
- Adding if_unsupported_attribute_callback helper and if_basic_attribute if helpers for java code generation
- Deprecating java and python zcl type helpers with new zcl type helpers such that they do not need any stateful information coming from parent block helpers. For eg chipType and chipCallback.type
- Adding tests for all the newly introduced helpers.
- Updating Api documentation
- Adding if_is_data_type_signed and as_zcl_data_type_size to determine sign and size of zcl data types
- if_is_data_type_signed and as_zcl_data_type_size take type name and cluster id to return size and sign of the zcl data types
- Github: ZAP#898

* Add some more content-based matter tests.
* Check the content to further depth of details.
* Add a cautionary tale that nobody will read... :(
* Get coverage reports.
* Clean up some typos.
* Use proper English.
* Remove xvfb-run, we do not need it.
* Clean up coverage for cypress, which is not being produced.
* Add the differently-ordered list to the generation.
* Fix the code coverage job.

* Cut down unnecessary repeat generations from same source.
* Break up zigbee tests into individual generations.
* Split database files.
* Fix the problem with the result.
* Clean up some custom package stuff.
* Consistently name tests.
* Add another generation for performance analysis.
* Add a full-th test for performance analysis.
* Sort out some nuances of the test.
* Separate each individual file for generation.
* There is no need to run Zigbee cypress tests twice.
* Support array for generateOnly option, and limit unit test generation to just what we test.
* Exclude more generations of things not needed for tests.
* Restore Matter test data to reasonably recent, and mandate the Matter tests to pass without errors.
* Add the all-clusters test for Matter.
* Bring back old matter XML files to keep Cypress fixtures happy.
* Comment out a code coverage. It was not doing much useful now, so we are commenting it out for now, until we restore it to correct functioning later, using the cache.

* Restore one matter unit test to being operational.
* Allow for sorting and omitting certain items in the struct population.
* Increase feature level.

* Add more tests for better coverage of the Matter-related JS code.

* Fix the importer to properly assign packages. Earlier, readFile() methods didn't even init packages.
* Separate the logic to initialize session key values from package defaults.
* Fix conversion process which suffered from double package init.
* Clean up unit tests to eliminate double session initialization.

* Add unit test for event field type checking.

We had earlier some 6 months old "Matter test data", that was mostly Zigbee test data with a single CHIP cluster.
Matter had gone far ahead, and people who were just working with zap, without access to main Matter SDK repo,
were only testing with old data. So this updates all the metafiles for Matter and patches the unit tests to
reflect that.

0) Isolate some queries for the device types. Clean up the old device type helper.
1) Add ability to query for device type clusters.
2) Fix a loading issue and several query issues
3) Move device type queries to proper location.  Access device type subentities, and fix a loading bug.
https://github.com/project-chip/zap/issues/472
 - There were no helpers earlier that would allow access to clusters and attribute/command overrides in the device lists. Now there are.
 - There was a loading bug that didn't link the DEVICE_TYPE_ATTRIBUTE and DEVICE_TYPE_COMMAND properly back to ATTRIBUTE and COMMAND tables.
4) Add reasonable ORDER BY to a query.
https://github.com/project-chip/zap/issues/494
5) Add ORDER BY to a query.
https://github.com/project-chip/zap/issues/497
6) Properly convert database booleans into JS bools.
https://github.com/project-chip/zap/issues/496

We used pattern expect(something.includes('x')).toBeTruthy().
That is wrong.
It's much better to use: expect(something).toContain('x') as you get an actual usable error message.

In a command argument loop checking if any of the arguments is of type
enum or bitmap the new helper function can determine this based on type.
Including for inhertied types.

Changes:
 - Expanded helper functions utility for bitmaps and enums