Implemented fetch_tracker to RepositorySimulator

[kairoaraujo]

This commit implements a feature in Repository Simulator to
track the fetch calls to the metadata and targets. This feature was
mentioned in PR #1666 that generated issue #1682.
This commit adds RepositorySimulator.fetch_tracker. It also changes
the tests/test_updater_consistent_snapshot.py to use the
fetch_tracker instead of using mock.

It implements a dataclass that stores the calls to fetch metadata
(_fetch_metadata) in fetch_tracker.metadata and targets
(_fetch_targets) in fetch_tracker.targets.

The fetch calls for metadata, and targets are stored as lists.

Signed-off-by: Kairo de Araujo [email protected]

Please fill in the fields below to submit a pull request. The more information
that is provided, the better.

Fixes #1682

Description of the changes being introduced by the pull request:

Please verify and check that the pull request fulfills the following
requirements:

• The code follows the Code Style Guidelines
• Tests have been added for the bug fix or new feature
• Docs have been added for the bug fix or new feature

[kairoaraujo]

I decided to submit a new PR after my big mess on PR #1704, and I have to say sorry.
I addressed all comments done by @sechkova

As mentioned by @sechkova in the PR #1704

Thanks, the trackers look good, I think this is what we needed.
My comments are minor, related to types but also I think one check is missing.

I was wondering if defining a dataclass (or two dataclasses for metadata and targets) instead of using tuples may simplify the expected calls lists. We can set default values and "typing" will be simpler but on the other hand instead of (root, 1) we'll have to write SomeCall(root, 1) ... so I am not sure about this. This is a way to say that I am looking for a second opinion, not requesting changes 😁 We can keep it like this for now, maybe when more use cases come this choice we'll be more obvious.

I also thought to have different dataclasses for metadata and targets in the initial design.

[coveralls]

Pull Request Test Coverage Report for Build 1553255010

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 97.581%

---

Totals
Change from base Build 1549318135:	0.0%
Covered Lines:	4032
Relevant Lines:	4116

---

💛 - Coveralls

[ivanayov]

Looks good to me, just one question

[sechkova]

Looks ok to me. Do you mind squashing the two commits before merging?

[jku]

Looks ok to merge to me but I did leave two comments. I can merge as is but maybe have a look and let me know what you think?

[jku]

Oh sorry, one more thing (trying to make life easier for @MVrachev): this PR probably has unused imports that will start failing with #1710 ? Can you check the unittest.mock imports?

Feel free to squash the PR to a single commit if you do end up making a change.

[kairoaraujo]

Thank you @jku, I will pay more attention.

[jku]

I think we'll go with this version :) thanks