The frontend rendering aims to not load the full TCA including
columns settings to reduce rendering time for full cache pages.

This approach is ridiculous complex and using it is so hard to get
right for developers that even core patches in this area are
usually broken. The current situation is neither simple
nor transparent.

Currently, if no page cache entry exists during rendering, the whole
ext_tables.php are executed, the page is rendered and stuffed to
cache. While the full TCA is available at this point, it is reduced
to the 'ctrl' sections for the next run, without 'columns', and
stuffed to cache. On next access, the cache entry is used,
ext_tables.php and TCA is not fully loaded. This leads to all sort of
problems, if for example those pages contain USER_INT plugins that
rely on some TCA settings. Furthermore, it might happen, that
different plugins or the core then requires the ext_tables files more
than once, which leads to funny problems if some developer does not
know this and uses require_once instead of require inside
ext_tables.php. Issues like that are very hard to track down.

The current implementation relies on the methods TSFE->includeTCA(),
TSFE->getCompressedTCarray() and GeneralUtility->loadTCA(), where
especially includeTCA() with its parameter is so hard to understand
that it is impossible to use in a correct way without digging through
the content rendering for hours.

The patch obsoletes all three of the above methods. Instead, from now
on, the bootstrap in the frontend is configured to always load the
full TCA including columns sections, even in full cached context.
The only exception are eID scripts, but the existing API to load
additional TCA in the eID controller is modified to also load all.

On the downside, this patch costs around 30% of additional
performance for the rendering of full cached pages. As soon as there
is some USER_INT on a page, or if a page is not cached, the overhead
is around zero. So, this patch costs performance for 'simple' pages,
while it is of no effect for anything more complex.

The goal is to reduce developer headaches at this point and to
make the frontend rendering better predictable and more easy
to maintain. It is furthermore one step to implement a better
configuration handling in the long run.

Change-Id: I5aecd542abe92f2de4ee0d40b5db44c493d304a3
Resolves: #45107
Releases: 6.1
Reviewed-on: https://review.typo3.org/17978
Reviewed-by: Oliver Hader
Tested-by: Oliver Hader
Reviewed-by: Wouter Wolters
Reviewed-by: Anja Leichsenring
Tested-by: Anja Leichsenring
Reviewed-by: Christian Kuhn
Tested-by: Christian Kuhn
Reviewed-by: Mattias Nilsson
Tested-by: Mattias Nilsson