Add buttons to FileInfo to automatically add missing include files

[mroda88]

Description

See CCM meeting https://indico.fnal.gov/event/74797/

Changes can be validate running DBE. Change an object in a file that has missing includes and see that the new buttons are functional.

Type of change

• Documentation (non-breaking change that adds or improves the documentation)
• New feature or enhancement (non-breaking change which adds functionality)
• Optimization (non-breaking change that improves code/performance)
• Bug fix (non-breaking change which fixes an issue)
• Breaking change (whatever its nature)

Testing checklist

• Unit tests pass (e.g. dbt-build --unittest)
• Minimal system quicktest passes (pytest -s minimal_system_quick_test.py)
• Full set of integration tests pass (dunedaq_integtest_bundle.sh)
• Python tests pass if applicable (e.g. python -m pytest)
• Pre-commit hooks run successfully if applicable (e.g. pre-commit run --all-files)

Comments here on the testing

Further checks

• Code is commented where needed, particularly in hard-to-understand areas
• Code style is correct (dbt-build --lint, and/or see https://dune-daq-sw.readthedocs.io/en/latest/packages/styleguide/)
• If applicable, new tests have been added or an issue has been opened to tackle that in the future.
  (Indicate issue here: # (issue))

[MRiganSUSX]

Thanks for this change @gcrone, very good idea.

Comments:

1. exception safety
   in src/structure/FileInfo.cpp: add_includefile, add_missing_schemafiles, add_missing_datafiles
   Manually m_updating toggling is risky. If ie file::add() throws, the flag stays true.
   Suggestion is to use QScopedValueRollback, ie:

#include <QScopedValueRollback>

void FileInfo::add_missing_schemafiles() {

  QScopedValueRollback<bool> guard(m_updating, true); 
  
  auto fname = prune_path(m_filename);
  if (s_missing_schema_map.contains(fname)) {
    for (const auto& file : s_missing_schema_map.at(fname)) {
      config::api::commands::file::add(m_filename, file);
    }
  }
  parse_includes();
  parse_objects();
}

2. map access
   in src/structure/FileInfo.cpp inside parse_objects() and check_file_includes()
.at() can throw out of range if the key is missing
   suggested to add a safety check, ie:

auto fname = prune_path(m_filename);
if (s_missing_schema_map.contains(fname)) {
    m_ui->add_missing_schema->setVisible(!s_missing_schema_map.at(fname).empty());
}

3. map mem leak
   in include/dbe/FileInfo.*
   the maps are not destroyed
   the suggestion is to add explicit destructor ie:

• header

~FileInfo();

• cpp

FileInfo::~FileInfo() {
    auto fname = prune_path(m_filename);
    s_missing_schema_map.erase(fname);
    s_missing_data_map.erase(fname);
    s_obj_map.erase(fname);
}

more generally, any reason the map objects (s_obj_map, s_missing_schema_map, s_missing_data_map) are static instead of standard non-static private members?

4. path comparison
   in src/structure/FileInfo.cpp inside match_path()
   same as in OKS, .endsWith() relies heavily on proper naming and can cause false positives.
   suggested to use QFileInfo:

#include <QFileInfo>

bool FileInfo::match_path(const QString& file, const QString& top_file, const QStringList& includes) {
  // Compare file names instead of full path strings
  if (QFileInfo(top_file).fileName() == QFileInfo(file).fileName()) {
    return true;
  }

[MRiganSUSX]

I understand some of these have nothing to do with the PR changes.
If preferred, we can just move these points to a separate issue.

[gcrone]

To answer the comments above:

1. Good suggestion, I hadn't heard of QScopedValueRollback. I didn't realise you were a Qt expert ;)
2. It may be overkill but I will add some checks
3. The maps are static and should not be removed in the destructor since they may be used by other instances. It is not really a memory leak since there is only ever one copy. The reason for the static variables is that it was a little bit of a kludge to re-use the code from the FileInfo class to ceck the includes in the save database function in the main window. I should really split the FileInfo checking from the FileInfo widget.
4. The problem with path comparison is that the paths are relative to DUNEDAQ_DB_PATH and only the end portion is guaranteed to match.