more local variable

Change-Id: Ibe67ecdd5b121ad5624bfd111dca33897d6e1991
use bookmarks to mark mailmerge parts in a mailmerge document (fdo#80823)

Instead of page numbers, which
- was somewhat fragile (and broken, as it was actually off-by-one)
- required repeated re-layout of the increasingly large document, making
  mailmerge awfully slow. The re-layout is not removed by this commit, as
  it needs further checking whether it can be removed.
See the bugreport for details.

Conflicts:
	sw/inc/doc.hxx
	sw/source/core/doc/docnew.cxx
	sw/source/ui/dbui/mmoutputpage.cxx
	sw/source/uibase/dbui/dbmgr.cxx
	sw/source/uibase/inc/mmconfigitem.hxx

Change-Id: Ib09bd5f5a6a549c3d38ca40b0f32c0d2831fdd4c
compute page offset for mailmerge based on source document rather than target

This removes another need for doing repeated and expensive layouts of the target
document.

Conflicts:
	sw/inc/doc.hxx
	sw/source/core/doc/docnew.cxx
	sw/source/uibase/dbui/dbmgr.cxx

Change-Id: Id78bc3ccc71c17e42f858dc9660866b9c94dea3a
do not repeatedly relayout mailmerge document after each change

When mailmerge uses a single document for all the generated documents, doing
a layout of this increasingly large document after every generated document
addition was getting slower and slower (no wonder). My recent changes should
have removed all needs for any layout in progress, so it should be enough
to just once calculate the final layout. The final layout still appears to be
needed, leaving it as it is to get layout done on the fly puts e.g. 2-page
documents on wrong starting page (maybe just invalidating something would fix
that).
Debug build shows warnings from vdraw.cxx about moving anchor from an invalid
page because of broken layouting, but those were there already before, so I
assume those are not really significant (or at least made worse by this commit).

Conflicts:
	sw/source/uibase/dbui/dbmgr.cxx

Change-Id: I62601ad6dccaa008783d1ce34c9e4f66f9621a56
SwXTextPortionEnumeration ctor: avoid dynamic_cast in the common case

For a document of 1000 pages and with 1000 bookmarks, this brings a
considerable speedup on ODF export:

before:
real    3m28.187s
after:
real    2m51.565s

Change-Id: Ic3f85c727a8ea4b5012d5c3f0a5887ff47762fb8
sw: add API that provides fast access to marks of a text node

sw::mark::MarkManager already provides two methods to provide not so slow mark
access:

- some marks (bookmarks, annotation marks) have their own container, so it's
  possible to iterate over only those types, not all of them
- the containers are sorted by the start position of the marks, so it's easy to
  ignore marks that are after the current text node

However, it's not possible to ignore marks ending before the current text node.
This is a problem, as e.g. during ODF export, we have to iterate over every
bookmark for each paragraph, so the operation is not linear.

On the other hand, the start and end position of bookmarks are stored using
SwPosition, and the SwIndex of the SwPosition is already registered in the
SwIndexReg of the SwTxtNode, so the text node sort of already knows what
bookmarks start/end at the current paragraph, it just doesn't known which
position belongs to what mark (if it belongs to a mark).

Fix the problem by adding a pointer to SwIndex that can optionally point back
to the mark that owns it. Also, in the sw::mark::MarkBase methods (which are
the only ones allowed to touch those positions) always set that pointer. With
this, it's possible to get the bookmarks of a node (list of bookmarks which
start or end in the current node) in a much faster way for text nodes.

Conflicts:
	sw/inc/index.hxx
	sw/source/core/bastyp/index.cxx

Change-Id: I7ceeff4dce852b4d72f2a73ae6a2423c7a781e41
sw: use new bookmark API in lcl_FillBookmarkArray() for text nodes

For a document of 1000 pages and having 13000 bookmarks, this helps a
lot on ODF export: 2m51.565s -> 2m23.412s on my machine.

Conflicts:
	sw/source/core/unocore/unoportenum.cxx

Change-Id: I8c8a7cd2b83a94ab7f2de17e0b4cb449fc4c0e1a
SwDBManager::MergeMailFiles: set unique fly names at the end of the merge

When generating a unique fly name, we have to iterate over all the
existing flys to find out what's the first not used one, so doing this
for every new fly inserted by mail merge is O(n^2).

During import, we already skip this and only do it once at the end of
the import, which is O(n).

Fix the performance problem by skipping the unique fly name generating
when we produce a combined mail merge document as well, and just
generate them once the mail merge is complete.

For a test document having 12 text frames and 2000 mail merge records,
the times for css::text::MailMerge::execute() is 9m37.330s -> 8m18.811s.

Conflicts:
	sw/inc/doc.hxx
	sw/source/core/doc/DocumentLayoutManager.cxx
	sw/source/uibase/dbui/dbmgr.cxx

Change-Id: Idfa8e9fe3acc93f1138f5bb12c2419c1492f8ff1
name of mailmerge marks is actually irrelevant

UNO bookmarks have internals names and ignore this

Conflicts:
	sw/source/uibase/dbui/dbmgr.cxx

Change-Id: I37baa4c9bcf9cec37f91e3b1d0fb2fad322ceda8
do not iterate over all bookmarks in SwTxtNode::Update()

3f9872185e introduced new API for fast finding of marks to a specific text node,
so use that (code itself based on cb46aaf2d7).
This makes mailmerge faster (since it can create a huge document, and especially
with the change to use UNO bookmarks to mark starts of MM documents inside
the larger single document there can be a large number of marks).

Conflicts:
	sw/source/core/txtnode/ndtxt.cxx

Change-Id: I30ec69acf423e9a62fae5f5492ed8744cb727a56
actually use return value of GetUniqueSectionName() in SwDoc::UpdateSection()

Change-Id: I6d9ae98e900e5e42c5253ee9b2f71bec351b54d1
Moved 'DateTimeToOString' from 'filter' package to 'tools' package

After the move now other classes can convert DateTime to OString also

Reviewed on:
	https://gerrit.libreoffice.org/6816

Conflicts:
	sw/source/filter/ww8/docxattributeoutput.cxx

Change-Id: I0ceb9a5cc26103a6cb36d7765a717770ec3fbe7d
do not bother with nice unique names during mailmerge

When using a single document for all the generating MM documents, there can
be a significant number of sections/etc. , enough to make searching them
all in order to find a next nice unique name take a noticeable time. Since
it's very unlikely anybody will ever care about nice names after mailmerge,
just get some unique name in a fast way.

Conflicts:
	sw/source/core/doc/docbm.cxx
	sw/source/core/doc/doclay.cxx
	sw/source/core/doc/docnum.cxx
	sw/source/core/doc/doctxm.cxx
	sw/source/core/docnode/ndsect.cxx
	sw/source/core/inc/MarkManager.hxx

Change-Id: Id6b8d39a67529984cb93bb369f2c6eab401f1799
do not break encapsulation of SwFmtAnchor::GetCntntAnchor()

Conflicts:
	sw/source/core/doc/DocumentContentOperationsManager.cxx
	sw/source/core/frmedt/fefly1.cxx
	sw/source/core/frmedt/feshview.cxx
	sw/source/core/layout/flycnt.cxx
	sw/source/core/txtnode/atrflyin.cxx

Change-Id: I0a320eb990f9a3b6800447a97a84c118239bae96
faster mapping from nodes to SwFrmFmt's anchored at them

The SwFrmFmtAnchorMap class provides reverse mapping
to SwFrmFmt::GetAnchor().GetCntntAnchor(), so that when code somewhere needs
to update SwFrmFmt's anchored at a position, it's not necessary to iterate
over all of them (which can be a large number e.g. with mail merge).

One special catch with the multimap of SwNodeIndex keys is that
the values of those keys change (whenever the node structure of the document
changes, indexes of nodes change as a result). This makes it impossible to use
any hashing container, as the hashes would change without the container
noticing, but multimap should work fine, as it just requires that the keys
remain sorted, and that is the case. Nevertheless, the old code in the two
converted places is intentionally left there in debug mode to verify the reverse
mapping is updated correctly.

I intentionally went with SwNodeIndex rather than SwPosition, as SwIndex
(the other component of SwPosition) was causing some trouble (see e.g. the
SwPosition comparison operator< , where two same positions are different if one
is registered and the other not) and it doesn't appear to be actually necessary.

Conflicts:
	sw/inc/doc.hxx
	sw/inc/frmfmt.hxx
	sw/source/core/attr/swatrset.cxx
	sw/source/core/doc/docnew.cxx
	sw/source/core/inc/frmtool.hxx
	sw/source/core/layout/atrfrm.cxx
	sw/source/core/txtnode/ndtxt.cxx

Change-Id: I7f1768558f60155d4ba83c84aa7f9e34dc65ebf9
speed up SwDoc::IsInHeaderFooter() by using SwFrmFmtAnchorMap

Now that it's possible to quickly find anchored objects for a node,
it's actually faster to check the node hiearchy rather than layout.

Conflicts:
	sw/source/core/doc/doclay.cxx

Change-Id: I5f93d5af32c744f1773535e5ec8537334d1ff58a
avoid unused argument warning

Change-Id: Ib67b804423b521407710f8319cb89977e44494cc
move the removeTree function from desktop to unotools

(cherry picked from commit 124a29f0f8dd805ef1d67bd062e1978a8a88e759)

Conflicts:

	desktop/source/app/app.cxx

Change-Id: I98d3f4a68abfee42dac987633878b850134671d3
sw: fix massive temp dir leak in SwModelTestBase

(cherry picked from commit beb45beba1529b0706a8dbe732c71b19493bcd7e)

Conflicts:
	sw/qa/extras/inc/swmodeltestbase.hxx

Change-Id: I92455612c41564e74570b4ee4fa4e3cdfa20f24d
sw: simplify the temp-file leaking debug code in mail-merge

(cherry picked from commit a4c9c8b3fb50e5b0344f77b57db757ebbb679144)

Conflicts:

	sw/source/uibase/dbui/dbmgr.cxx

Change-Id: Ib0de8cc5977a8721511e62f39bf3a86a6a76250a