[4.3] KZ00-41: handle number delete conflicts (#6285)

* [4.3] KZ00-41: handle number delete conflicts

Previously, when deleting the number document from the account
database, a conflict almost always occurred on the first delete
attempt as the number doc from the number database was used (which
contained a different _rev).

However, `knm_phone_number:retry_conflicts/4` only had code for saving
to the target database (the account). The result is that the number
doc (now in the "available" state) would be `ensure_saved` to the
account database, resulting in number listings for the account to both
show the number belonging to the account *and* show it as "available",
an internal state that clients should not see.

This changeset provides additional context to handle_bulk_change about
what type of change, 'delete' or 'save', and informs retry_conflicts
of how to proceed.

Secondly, the likelyhood of conflict is high when saving/deleting from
the account database as the JSON object used is the number db's
version. `try_delete_from` has been updated to use just the number as
ID and lets kz_datamgr build the tombstone and delete accordingly.

* use macro-ized db_exists

* just assert the truth

* no need to be so loud

core/kazoo_data/src/kzs_doc.erl

@@ -202,7 +202,7 @@ prepare_publish(JObj) ->
 
 -spec maybe_tombstone(kz_json:object()) -> kz_json:object().
 maybe_tombstone(JObj) ->
-    maybe_tombstone(JObj, kz_json:is_true(<<"_deleted">>, JObj, 'false')).
+    maybe_tombstone(JObj, kz_doc:is_deleted(JObj)).
 
 -spec maybe_tombstone(kz_json:object(), boolean()) -> kz_json:object().
 maybe_tombstone(JObj, 'true') ->

core/kazoo_number_manager/src/knm_locality.erl

@@ -20,7 +20,7 @@
 fetch(Numbers) when is_list(Numbers)->
     case knm_config:locality_url() of
         'undefined' ->
-            lager:error("could not get number locality url"),
+            ?LOG_WARNING("could not get number locality url"),
             {'error', 'missing_url'};
         Url ->
             Resp = fetch_req(Numbers, Url),