Removed explicit module references when they refer to functions in the same module

[ariel-anieli]

Proposed Changes

• 24 files are edited at once; if need be, I am willing to split this commit into many ones
• apart from comments, when called within the same module, replaced module:function/arity or module:type/0, by function/arity or type/0
• sef-references found with this command:

git grep -n : | perl -nE 'print if m;/([\w_]+)\.erl:.*[^\w_]\g1:[\w_]+\(; && !/%/'

Types of Changes

• Bug fix (non-breaking change which fixes issue #NNNN)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause an observable behavior change in existing systems)
• Documentation improvements (corrections, new content, etc)
• Cosmetic change (whitespace, formatting, etc)
• Build system and/or CI

Checklist

• I have read the CONTRIBUTING.md document
• I have signed the CA (see https://cla.pivotal.io/sign/rabbitmq)
• I have added tests that prove my fix is effective or that my feature works
• All tests pass locally with my changes
• If relevant, I have added necessary documentation to https://github.com/rabbitmq/rabbitmq-website
• If relevant, I have added this change to the first version(s) in release-notes that I expect to introduce it

Further Comments

None.

[michaelklishin]

Thank you for taking the time to contribute.

This kind of PRs presents a few serious headaches for us maintainers:

• When something fails, like bazel test //deps/rabbit_common:all on Actions, it's difficult to narrow down what change may be causing this because they are all over the place
• git blame output becomes harder to follow
• Semi-automated or automated changes like this are risky because even the best IDEs sometimes cannot semantically correctly determine if two matching strings are indeed the same code element

I cannot reproduce the failure on two different machines but this PR does not really address any practical problem. The compiler will figure out that a module:function/arity call is local and all the same optimizations should apply.

So I would like to accept this contribution but it's too hard to justify.

This is now the 3rd or so time when your PRs are rejected. I suggest that you look into a recent practical problem to work on. Those are usually much more focussed and easier to evaluate.

[michaelklishin]

I will try to port some of these manually to see where things may start breaking in that one rabbit_common suite.

[michaelklishin]

The majority of changes apply without breaking any test suites: #10481.

[ariel-anieli]

Thanks for having taken up this PR, @michaelklishin; your explanation made me understand it was a hassle to review.
I'll look into more recent and more scoped problems; I might ask for clarifications: I've only been contributing for a month.