Add more logging around catalog source sync

[perdasilva]

Description of the change:

A recent live debugging session revealed that the catalog source reconciliation loop is under logged. This PR adds more logging. Generally, I've tried to:

• log start and end of method calls
• log errors as close as possible to source
• call out steps in the methods

Motivation for the change:

Architectural changes:

Testing remarks:

Reviewer Checklist

• Implementation matches the proposed design, or proposal is updated to match implementation
• Sufficient unit test coverage
• Sufficient end-to-end test coverage
• Bug fixes are accompanied by regression test(s)
• e2e tests and flake fixes are accompanied evidence of flake testing, e.g. executing the test 100(0) times
• tech debt/todo is accompanied by issue link(s) in comments in the surrounding code
• Tests are comprehensible, e.g. Ginkgo DSL is being used appropriately
• Docs updated or added to /doc
• Commit messages sensible and descriptive
• Tests marked as [FLAKE] are truly flaky and have an issue
• Code is properly formatted

[stevekuznetsov]

I think in practice you'll find method book-ending is extremely chatty - on the order of MiB/s logging rate during high churn, especially when the system is just verifying correctness of current state and not changing. Not sure if you really require it. The logs for error cases and outcomes are very useful and will not emit if "nothing" is going on.

[perdasilva]

yeah - I tend to agree. The verbosity is high for low utility. I'll cull most of the non-error logs. At least in these paths, anyway. Wondering if just leaving pre-return log would still be a good idea to get signal that it went into the method - even if only for the methods higher up the stack....?

[perdasilva]

okie - see if that sparks joy, or if you reckon it's still too verbose

[stevekuznetsov]

Try it out and see! It might still be too chatty to be useful, but you can't know without running an end-to-end test.