subscriptionsPerFabric in basic cluster has incorrect values

[mrjerryjohns]

Problem

Reading out subscriptionsPerFabric gives a really large number (which might be accurate on heap-based platforms anyways), but looked suspicious.

Looks like the logic is off in InteractionModelEngine::GetMinSubscriptionsPerFabric():

    size_t perFabricSubscriptionCapacity = static_cast<size_t>(readHandlerPoolCapacity - kReservedPathsForReads) / fabricCount;

That should be kReservedHandlersForRead, not paths.

Also, GetReadHandlerPoolCapacity is not quite handling heap-based platforms today, resulting in an advertised number lower than the capability of the platform.

[mrjerryjohns]

Last of all, the computation of the value is dividing the total available resources by the number of currently commissioned fabrics. This is not compliant with what the spec is actually saying here (which is requiring the minimum number of subs supported per fabric assuming at least 5 fabrics could be commissioned on the device).

[bzbarsky-apple]

So we need two functions: the bare minimum we guarantee per fabric (which depends on max fabrics), and the value the resource-allocation logic needs, which is depends on our actual number of fabrics.

[erjiaqing]

Note: Since #18884 touched the macros for resource minimals, the original issue is fixed already.

[cjandhyala]

fixed in the latest SDK(c60233d) , verified on RPI.