[meta][sai] Move extensions SAI and API to 0x20000000 range

[kcudnik]

To make this binary backward compatible for extension enums, instead of starting form _ATTR_END and prevent enum shift each time new attribute is added

Update saisanitycheck to not use object type as index

Since we will move object type extensions to separate range we will need to update many shortcuts taken by saisanitycheck
when it was using object type as index to fast access arrays

NOTE: this will break current logic in sonic-saireids lib and vslib oid managers, also in https://github.com/sonic-net/DASH/blob/main/dash-pipeline/SAI/src/objectidmanager.cpp, since object type with extensions will not possible to encode on a single byte. Corresponding PR fixes will be made to mitigate this issue.

[kcudnik]

@marian-pritsak please take a look

[kcudnik]

This commit will be require to update sonic-sairedis repo with this commit: sonic-net/sonic-sairedis#1390

[kcudnik]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[rck-innovium]

The summary of the SAI discussion was :

1. Custom range is to be used for attributes/enums/stats for vendor specific attrs
2. The newly added extensions' base is to be used for attributes/enums/stats to be defined in experimental directory (for experimental features)
3. Extensions base is added to switch and port since they are the only ones used in SAI extensions. Extensions based will be added to other objects when they are needed.

[kcudnik]

NOTE: sai backward compatibility for enums is not checked in experimental directory due the dash api are changing often, we could enable backward compatibility check for specific apis/types, let me know

[r12f]

hi Kamil, just found that these attributes are removed. do we need to keep them but maybe with a different value?

[kcudnik]

currenty those are not needed, and they were added to fix gcc error, do a git blame and find commit for that change, if we want to add those back, then they need to start as custom range for other enums 0x10000000

[r12f]

NOTE: sai backward compatibility for enums is not checked in experimental directory due the dash api are changing often, we could enable backward compatibility check for specific apis/types, let me know

yea, I believe this is ok. maybe some day what we need to do it to move dash outside of the experiment folder but into another folder maybe called extension

[kcudnik]

Please check in this change if there is no conflicts and approved @rlhui @lguohan

[kcudnik]

Ping

[kcudnik]

i decribed issue on the on the github comment:
sonic-net/sonic-buildimage#20725 (comment)

and yes, if if DASH is implemented in the SAI lib, on older version thatn v1.15.0 then it's before enums DASH shifted, so if we use v1.15.0 headers with v1.14.0 libsai, then new port attributes will overlay DASH extensions, and return output will not match the attribute type

i proposed solution for that to update metadata for each attribute with specific attribute version when it was introduced, so comparing version with libsai will prevent that

of course for dash attributes, currently syncd is not using that, but that enum shift to range 0x20000000 is not backward compatible, so there is no easy fix for that, also syncd is not doing discovery on experimental headers, and since they can change any time, then there is no point to assign version to those attributes