Could you please take a look at this and maybe advise on how to proceed with the investigation more efficiently.
See http://blog.jcole.us/2014/04/16/the-basics-of-the-innodb-undo-logging-and-history-system/.
While InnoDB purge does freeing undo log pages and unlinking them from the global history list to make them available for re-use. They remain on ibdata file. These free pages are never currently returned to OS and naturally there are several situations where these pages can't be really re-used e.g. on situation where new undo pages are bigger than fragmented datafile pages.
I do not know any means to really investigate after something mysterious has happened, only way is to monitor current disk usage and if some unexplained allocations are done see what operations really did cause that.
According to the initial description, the mysteriously big ibdata file is available. Is there any way to analyze its contents to see what really takes all the space, whether it the undo pages or anything else?
As we have already reported, 97% of pages consists of undo pages indeed, but the size of the data is too big to have been produced by normal usage. So, we suspect that something has stuck and caused an abnormal amount of undo logs to be written. Since an infinite loop could lead to a lot of undo logs written with the same 
data, we may need to analyze that data for repeating patterns and then see if there is a code path that could lead to such loop...
It's also important to note that this happened only few days after we intorduced the "INSERT INTO ... SELECT ..." issue in our code and has not happened again since fixing this. So, it is very likely that the bug was triggered by our, at that time, unoptimized code.
The worst case scenario with regard to undo log growth involves big transactions with DML operations and long-running transactions (which could be the large DML operation, or just some read-only transaction that was started but not committed yet).
It could be good to split big transactions into smaller ones, so that the undo logs can be discarded earlier. For INSERT operations, undo logs will be discarded already at COMMIT. For UPDATE or DELETE operations (or INSERT that overwrites a previously deleted record that had not yet been purged), the undo logs will be preserved until purge removes them.
Long-running transactions would prevent the InnoDB purge subsystem from removing old update_undo logs for transactions that were committed after the MVCC read view for the long-running transaction was started.
An unlikely possibility could be a bug in the InnoDB page allocation, causing the data file to grow even though reusable (freed) pages exist. https://bugs.mysql.com/bug.php?id=59783 was fixed in 2011.