Nested slot creates fallback even with override

[StrahilKazlachev]

I'm submitting a bug report

• Library Version:
  1.8.2

• Browser:
  all

• Language:
  all

Current behavior:
If we have nested slots the fallback content, for the nested one, gets created(ShadowSlot.prototype.renderFallbackContent gets called) even when there is an override provided for that slot. After that the fallback view is bound and unbound, it is never attached.

Expected/desired behavior:

• What is the expected behavior?
  Repro - I'm expecting that when I have nested <slot>s and target the nested one, its fallback content is not created, as is the case with unnested <slot>s.

• What is the motivation / use case for changing the behavior?

1. Unnecessary processing(bind/unbind) and allocation of resources since <slot>s are static, so the created fallback View will never be used.
2. In certain cases, when we have custom elements/attributes in the nested slot fallback, the unexpected binding/unbinding of the fallback View can lead to errors since unexpected(incorrect) data will get bound to them.

Observation
For nested slots with override for the nested one, it seems that when ShadowSlot.prototype.renderFallbackContent is called for the nested <slot>, it is done based on needsFallbackRendering evaluating to true because:

• at this time projections is still 0(for the nested one)
• the call to ShadowDOM.distributeView => ShadowDOM.distributeNodes, which will modify projections correctly is still to happen
• the call to ShadowDOM.distributeView is done during binding of the View