Deprecate mam02

[kanes115]

This PR adds a new module responsible for maintaining deprecations messages

[kanes115]

ejabberd.log from Build #3625/Job #3625.3 - entry with the error:
2017-10-11 09:12:02.656 [error] <0.21749.0>@mongoose_deprecations:deprecate_archived_element_message:96 Archived element is going to be deprecated in release 3.0.0. It is not recommended to use it. Consider using a <stanza-id/> element instead

EDIT: After a small commit (#6472465) the mesage should look like this:
2017-10-11 09:12:02.656 [error] <0.21749.0>@mongoose_deprecations:deprecate_archived_element_message:96 <archived/> element is going to be removed in release 3.0.0 It is not recommended to use it. Consider using a <stanza-id/> element instead

[kanes115]

@fenek, is it waiting to be merged or needs some corrections (and you did not change the label nor make any comment on that)?

[fenek]

This is not very generic. This module shouldn't provide an implementation specific for certain deprecations, as it unnecessarily increases coupling. The API should be log(Tag :: atom(), Level :: atom(), FormatStr :: string(), Params :: list()) (with log(Tag, FormatStr, Params) may still default to error log level). There shouldn't be per-deprecation table but one global for all deprecations and its elements' keys should be {Tag, last_logged} or just Tag. I think we may stick to common cooldown time for all deprecations for now.

[kanes115]

I thought of this module as tightly coupled with those that want to "call themselves" deprecated, as a module that knows about specific modules and the way each of them wants to annnounce the deprecation. So that now module itself just needs to trigger log/1 function whenever it wants to log deprecation message and here is the logic responsible for cooldowns, log format, preparing necessary ETS tables etc.

What would be the gain for creating a module with only a log message?
Moreover - it wouldn't be too generic if we say each deprecation has some kind of cooldown. Maybe some deprecation messages are shown at Mongoose's start or shutdown and not triggered by some event as <archived/> is?

I see this module as one that:

• exposes API for starting and stoping it (where it creates all the stuff that is needed to handle different types of deprecations e.g. creating ETS tables or registering hooks
• exposes API to log such a warning

@fenek, tell me how is your vision different from this one so that I can make necessary corrections. :)

[kanes115]

We could make it the other way round:
make mongoose_deprecations' functions callbacks and make modules implement them. That would loosen the coupling between them and this new module but on the other hand we will have this quite a huge piece of code that is only responsible for deprecating (which is not part of the main job of the module).

[kanes115]

We can also go in the direction that all deprecations look alike - they have some cooldown and if module calls our log function we first check if it's not logged too early.

[kanes115]

So, as I guess you probably meant the third options, I will stick to that

[kanes115]

Do we want the list of deprecation tags to be loaded from config (possibly with their cooldown times), @fenek? Or do you want it the way it is now (or any other suggestions?)

[fenek]

To answer your question: Until there is a real need to fine-tune the warning frequency, I don't think it should be configurable at all. 6h is a good interval to be annoying but not a performance issue.

[fenek]

This module shouldn't be aware of how many deprecations there are.

[fenek]

No need to pre-fill this table.

[kanes115]

@fenek, I have implemented tests. You can take a look ;)

[kanes115]

@fenek, I have doubts about this test. Firstly, to be able to mock the function from the module I test I had to call it this way:
https://github.com/esl/MongooseIM/pull/1514/files#diff-682046812c1745a45d518b7aca59f622R104
Secondly, I had to export it when compiling for tests:
https://github.com/esl/MongooseIM/pull/1514/files#diff-682046812c1745a45d518b7aca59f622R23

I'm mocking function that directly calls lager:warning/2 or lager:error/2. I found it very hard to mock lager as its functions are created in parse transform so they don't exist when I want to mock them.