The res_pjsip_exten_state module currently has a race condition between
processing the extension state callback from the PBX core and processing
the subscription shutdown callback from res_pjsip_pubsub. There is currently
no synchronization between the two. This can present a problem as while
the SIP subscription will remain valid the tree it points to may not.
This is in particular a problem as a task to send a NOTIFY may get queued
which will try to use the tree that may no longer be valid.

This change does the following to fix this problem:

1. All access to the subscription tree is done within the task that
sends the NOTIFY to ensure that no other thread is modifying or
destroying the tree. This task executes on the serializer for the
subscriptions.

2. A reference to the subscription serializer is kept to ensure it
remains valid for the lifetime of the extension state subscription.

3. The NOTIFY task has been changed so it will no longer attempt
to send a NOTIFY if the subscription has already been terminated.

ASTERISK-25057 #close
Reported by: Matt Jordan

Change-Id: I0b3cd2fac5be8d9b3dc5e693aaa79846eeaf5643

Creating a snoop channel in ARI and spying only on a single direction (in or
out) results in CPU utilization continually increasing until the CPU is fully
consumed. This occurs because frames are being put in the opposing direction's
slin factory queue, but not being removed.

Fixed the problem by always reading and disposing of frames from the opposite
queue of the direction selected.

ASTERISK-24938 #closes

Change-Id: I935bfd15f1db958f364d9d6b3b45582c0113dd60

Missed this module in the previous commit.  res_ari_bridges uses symbols
from res_stasis_playback and res_stasis_recording.

ASTERISK-25027 #close
Reported by: Corey Farrell

Change-Id: I90bf756abd25adfc4920d2869ebe7feb636b8c5f

* Pass module to ast_cli_register and ast_cli_register_multiple.
* Add a module reference before executing any CLI callback, remove
  the reference when complete.

ASTERISK-25049 #close
Reported by: Corey Farrell

Change-Id: I7aafc7c9f2b912918f28fe51d51e9e8a755750e3

ast_module_info->self is often needed to register items with the core.  Many
modules have ad-hoc code to make this pointer available to auxiliary sources.
This change updates the module build process to make the needed information
available to all sources in a module.

ASTERISK-25056 #close
Reported by: Corey Farrell

Change-Id: I18c8cd58fbcb1b708425f6757becaeca9fa91815

Apply the negative connection cache setting to all connections,
even those that are not pooled. This ensures that the connection
will not be  re-established before the negative connection cache
time is met.

ASTERISK-22708 #close

Change-Id: I431cc2e8584ab0b6908b3523d0a0e18c9a527271

Removed the extra space before "MODULEINFO" in res_pjsip_dlg_options.
This extra space prevented any of the dependencies from being seen by
menuselect, so building with default options would fail if PJSIP was
not installed.

This also makes the tool that extracts information for menuselect
tolerant of multiple spaces in the future.

ASTERISK-25033 #close
Reported by: Peter Whisker

Change-Id: Iccd54846f70c4a7a50cb5bf70b7bb5cb4bab3698

The res_ari_device_states module depends on res_stasis_device_state,
not res_stasis_device_states.

Change-Id: I26e02ad37f9e36bcc859867e2fad1b90452ec3de

This patch has two main purposes:

1) Improve warning messages when ACLs are configured improperly.
2) Prevent misconfigured ACLs from allowing potentially unwanted
traffic.

To acomplish point (2) in most cases, whatever configuration object that
the ACL belonged to was not allowed to load.

The one exception is res_pjsip_acl. In that case, ACLs are their own
configuration object. Furthermore, the module loading code has no
indication that a ACL configuration had a failure. So the tactic taken
here is to create an ACL that just blocks everything.

ASTERISK-24969
Reported by Corey Farrell

Change-Id: I2ebcb6959cefad03cea4d81401be946203fcacae

When the PJSIP pjsip_regc_send function is invoked and an error
status returned the caller currently decrements the reference count
of the client state that it just incremented, assuming the
registration callback would not have been invoked. In practice
this is not correct. If the failure happens after the transaction
has been set up the callback will still be invoked. This will
cause the reference count to be incorrectly decremented twice, once
by the registration callback and second by the caller of
pjsip_regc_send.

This change makes it so that whether the callback is invoked or
not is known by the caller of pjsip_regc_send. Depending on
this it can know whether it is responsible for decrementing the
reference count of the client state or not.

ASTERISK-25037 #close
Reported by: Joshua Colp

Change-Id: I749dc12f3a22115c49c5d7d95ff42a5fa45319de

A previous set of patches (see: ASTERISK-22790 & ASTERISK-23231) made it so
a v.27 modem was not allowed to have a minimum transmission rate of 2400 bits
per second. This reverts all or some of those patches since according to the
v.27ter standard a rate of 2400 bits per second is also supported.

One of the original patches also added 9600 bits per second support for v.27.
This patch also removes that since v.27ter only supports 2400/4800 bits per
second.

Also, since Asterisk specifically supports v.27ter the enum was renamed to
better reflect this.

ASTERISK-24955 #close
Reported by: Matt Jordan

Change-Id: I4b9dfb6bf7eff08463ab47ee1a74224f27cae733

Odd behaviors have been observed during outbound registrations. The most
common problem witnessed has been one where a request with
authentication credentials cannot be created after receiving a 401
response. Other behaviors include apparently processing an incorrect SIP
response.

Inspecting the code led to an apparent issue with regards to how we
handle transactions in outbound registration code. When a response to a
REGISTER arrives, we save a pointer to the transaction and then push a
task onto the registration serializer. Between the time that we save the
pointer and push the task, it's possible for the transaction to be
destroyed due to a timeout. It's also possible for the address to be
reused by the transaction layer for a new transaction.

To allow for authentication of a REGISTER request to be authenticated
after the transaction has timed out, we now hold a reference to the
original REGISTER request instead of the transaction. The function for
creating a request with authentication has been altered to take the
original request instead of the transaction where the original request
was sent.

ASTERISK-25020
Reported by Mark Michelson

Change-Id: I756c19ab05ada5d0503175db9676acf87c686d0a

Change-Id: Ic8322f04e37842848ad72cf2871bd0378f67c4ac

ARI modules that are generated by 'make ari-stubs' are all dependent on
res_ari_model.  Additionally some of the same modules depend on one or more
res_stasis_* modules.

ASTERISK-25027 #close
Reported by: Corey Farrell

Change-Id: I8e07fe7e81fedacb87232f2b6f8b5f47927b4153

Remove incorrect MODULEINFO block and unneeded header includes
from presence_xml.c.

ASTERISK-25027
Reported by: Corey Farrell

Change-Id: I977c609ab9d1fe05373027c4138900f6985990eb

This switches files used to generate other sources to use the new
ASTERISK_REGISTER_FILE macro.

ASTERISK-25026 #close
Reported by: Corey Farrell

Change-Id: Ieb2537b83421cad07c8955e5f90c405ccf079740

            Sections Exist in pjsip.conf

This patch modifies the current loading strategy of the pjsip configuration. If
duplicate sections (e.g. sections containing the same [id/type]) are defined in
[pjsip.conf], the loader will consider the configuration for the given type as
invalid when the duplicate section is encountered. The entire configuration
(including what was previously loaded) for the duplicate [id/type] sections
will be rejected and destroyed, an error message is logged and the load
processing for the given stops.

ASTERISK-24996
Reported By: Ashley Sanders

Change-Id: I35090ca4cd40f1f34881dfe701a329145c347aef

When problems occur regarding outbound registrations, it currently
is difficult to debug. Most off-nominal paths had warning messages,
but sometimes we want to know what's going on before hitting the
off-nominal path. This patch adds lots of debugging output that
should give a clearer picture of what is happening with regards
to outbound registrations.

ASTERISK-25020
Reported by Mark Michelson

Change-Id: I577bde7860be0a6c872b5bcb4d5047340bf45d45

ao2 ref leak in res_rtp_asterisk.c when a DTLS policy is created.
The resources are linked into a table, but the original alloc refs
are never released. ast_strdup leak in rtp_engine.c. If
ast_rtp_dtls_cfg_copy() is called twice on the same destination struct,
a pointer to an alloc'd string is overwritten before the string is free'd.

ASTERISK-25022
Reported by: one47

Change-Id: I62a8ceb8679709f6c3769136dc6aa9a68202ff9b

* The REF_DEBUG compiler flag no longer has any effect on code that uses
  Astobj2.  It is used to determine if reference debugging is enabled by
  default.  Reference debugging can be enabled or disabled in asterisk.conf.
* Caller information is provided in logger errors for ao2 bad magic numbers.
* Optimizes AO2 by merging internal functions with the public counterpart.
  This was possible now that we no longer require a dual ABI.

ASTERISK-24974 #close
Reported by: Corey Farrell

Change-Id: Icf3552721fe999365ba8a8cf00a965aa6b897cc1

Permanent contacts that hadn't been qualified yet were missing
their contact_status entries causing SEGVs when running CLI
commands.

This patch makes sure that contact_statuses are created for
both dynamic and permanent contacts when they are created.
It also adds checks in the CLI code to make sure there's a
contact_status, just in case.

ASTERISK-25018 #close
Reported-by: Ivan Poddubny
Tested-by: Ivan Poddubny
Tested-by: George Joseph

Change-Id: I3cc13e5cedcafb24c400368b515b02d7fb81e029

The way PJSIP generates an authenticated request is to use a previous
request as a template. This means that the authenticated request will
have the same Call-ID, From header (including tag), and CSeq as the
original request. PJSIP generates a new branch on the Via header to
indicate that this is a new transaction, though.

There are some SIP implementations, though, that do not notice the
change in the branch and therefore will match the authed request to the
original request's transaction. Since the CSeq is the same, the server
will repeat the response it sent to the original request.

This patch aids interoperability by increasing the CSeq of the authed
request by one.

ASTERISK-24845 #close
Reported by: Carl Fortin
Tested by: Carl Fortin

Change-Id: I39c4ca52e688a9f83bcc1878371334becdc5be01

clang can warn about a so called tautological-compare, when it finds
comparisons which are logically always true, and are therefor deemed
unnecessary.

Exanple:
unsigned int x = 4;
if (x > 0)    // x is always going to be bigger than 0

Enum Case:
Each enumeration is its own type. Enums are an integer type but they
do not have to be *signed*. C leaves it up to the compiler as an
implementation option what to consider the integer type of a particu-
lar enumeration is. Gcc treats an enum without negative values as
an int while clang treats this enum as an unsigned int.

rmudgett & mmichelson: cast the enum to (unsigned int) in assert.
The cast does have an effect. For gcc, which seems to treat all enums
as int, the cast to unsigned int will eliminate the possibility of
negative values being allowed. For clang, which seems to treat enums
without any negative members as unsigned int, the cast will have no
effect. If for some reason in the future a negative value is ever
added to the enum the assert will still catch the negative value.

ASTERISK-24917
Change-Id: Ief23ef68916192b9b72dabe702b543ecfeca0b62

When Asterisk originates a channel to an application, the channel is
hung up once the application finishes executing. When the application
in question is SendFax, the Asterisk PJSIP code will attempt to reinvite
the T.38 session to audio after the FAX completes. The hangup of the
channel happens in the midst of this reinvite transaction. In most
circumstances, this works out okay because the BYE is delayed until the
reinvite transaction can complete.

However, if the reinvite that Asterisk sends receives a 401/407
response, then Asterisk's attempt to re-send the reinvite with
authentication will fail. This is because the session supplement in
res_pjsip_t38 makes the assumption that the channel on the session will
always be non-NULL. Since the channel has been hung up, though, the
channel is now NULL. Attempting to operate on the channel causes a
crash.

This patch fixes the issue by ensuring that the channel on the session
is not NULL before attempting to mess with the T.38 framehook.

This patch also contains some corrections for comments that were
incorrect and really confused me when I first started looking at the
code.

ASTERISK-25004 #close
Reported by Mark Michelson

Change-Id: Ic5a1230668369dda4bb13524098aed9306ab45a0

Currently we use pjsip_parse_hdr to validate contact uris but it
appears that it allows uris without a scheme if there's a port
supplied.  I.E myexample.com will fail but myexample.com:5060 will
pass even though it has no scheme.  This causes SEGVs later on
whenever the uri is used.

To prevent this, permanent_contact_validate has been updated to check
that the scheme is either 'sip' or 'sips'.

2 uses of possibly-null endpoint have also been fixed in
create_out_of_dialog_request.

ASTERISK-24999

Change-Id: Ifc17d16a4923e1045d37fe51e43bbe29fa556ca2
Reported-by: Brad Latus

clang can warn about a so called tautological-compare, when it finds
comparisons which are logically always true, and are therefor deemed
unnecessary.

Exanple:
unsigned int x = 4;
if (x > 0)    // x is always going to be bigger than 0

Enum Case:
Each enumeration is its own type. Enums are an integer type but they
do not have to be *signed*. C leaves it up to the compiler as an
implementation option what to consider the integer type of a particu-
lar enumeration is. Gcc treats an enum without negative values as
an int while clang treats this enum as an unsigned int.

rmudgett & mmichelson: cast the enum to (unsigned int) in assert.
The cast does have an effect. For gcc, which seems to treat all enums
as int, the cast to unsigned int will eliminate the possibility of
negative values being allowed. For clang, which seems to treat enums
without any negative members as unsigned int, the cast will have no
effect. If for some reason in the future a negative value is ever
added to the enum the assert will still catch the negative value.

ASTERISK-24917

Change-Id: I0557ae0154a0b7de68883848a609309cdf0aee6a

On some systems, res_corosync isn't compatible with the installed version of
corosync so corosync_cfg_initialize fails, load_module returns LOAD_FAILURE,
and Asterisk terminates.  The work around has been to remember to add
res_corosync as a noload in modules.conf.  A better solution though is to have
res_corosync check for its config file before attempting to call corosync apis
and return LOAD_DECLINE if there's no config file.  This lets Asterisk loading
continue.

If you have a res_corosync.conf file and res_corosync fails, you get the same
behavior as today and the fatal error tells you something is wrong with the
install.

ASTERISK-24998

Change-Id: Iaf94a9431a4922ec4ec994003f02135acfdd3889

Currently the res_pjsip_mwi module only sends an unsolicited MWI NOTIFY upon
a mailbox state change (such as a new message being left, or one being deleted).
In practice this is not sufficient to keep clients aware of the current MWI status.

This change makes the module send unsolicited MWI NOTIFY on startup so that
clients are guaranteed to have the most up to date MWI information. It also makes
clients receive an unsolicited MWI NOTIFY upon registration so if they are unaware
of the current MWI status they receive it.

ASTERISK-24982 #close
Reported by: Joshua Colp

Change-Id: I043f20230227e91218f18a82c7d5bb2aa62b1d58

When SUBSCRIBE dialogs were established, we never associated
the endpoint that created the subscription with the dialog
we end up creating. In most cases, this ended up not causing
any problems.

The actual bug that was observed was that when a device that
was behind NAT established a subscription with Asterisk, Asterisk
would end up sending in-dialog NOTIFY requests to the device's
private IP addres instead of the public address of the NAT router.

When Asterisk receives the initial SUBSCRIBE from the device,
res_pjsip_nat rewrites the contact to the public address on which the
SUBSCRIBE was received. This allows for the dialog to have its target
address set to the proper public address. Asterisk then would send a 200
OK response to the SUBSCRIBE, then a NOTIFY with the initial
subscription state. The device would then send a 200 OK response to
Asterisk's NOTIFY.

Here's where things went wrong. When the 200 OK arrived, res_pjsip_nat
did not rewrite the address in the Contact header. Then, when the PJSIP
dialog layer processed the 200 OK, PJSIP would perform a comparison
between the IP address in the Contact header and its saved target
address for the dialog. Since they differed, PJSIP would update the
target dialog address to be the address in the Contact header. From this
point, if Asterisk needed to send a NOTIFY to the device, the result was
that the NOTIFY would be sent to the private address that the device
placed in the Contact header.

The reason why res_pjsip_nat did not rewrite the address when it
received the 200 OK response was that it could not associate the
incoming response with a configured endpoint. This is because on a
response, the only way to associate the response to an endpoint is by
finding the dialog that the response is associated with and then finding
the endpoint that is associated with that dialog. We do not perform
endpoint lookups on responses. res_pjsip_pubsub skipped the step of
associating the endpoint with the dialog we created, so res_pjsip_nat
could not find the associated endpoint and therefore couldn't rewrite
the contact.

This commit message is like 50x longer than the actual fix.

ASTERISK 24981 #close
Reported by Mark Michelson

Change-Id: I2b963c58c063bae293e038406f7d044a8a5377cd

Contact status rtt is an int64_t and needs the PRId64 macro to
properly create the format specifier on 32-bit systems.

Change-Id: I4b8ab958fc1e9a179556a9b4ffa49673ba9fdec7

The "Add qualify_timeout processing and eventing" patch introduced
an issue where contacts that had qualify_frequency set to 0 were
showing Unavailable instead Unknown.  This patch checks for
qualify_frequency=0 and create an "Unknown"  contact_status
with an RTT = 0.

Previously, the lack of contact_status implied Unknown but since
we're now changing endpoint state based on contact_status, I've
had to add new UNKNOWN status so that changes could trigger the
appropriate contact_status observers.

ASTERISK-24977: #close

Change-Id: Ifcbc01533ce57f0e4e584b89a395326e098b8fe7

Three fax related tests started failing as a result of changes made for
ASTERISK-24841:
tests/fax/pjsip/gateway_t38_g711
tests/fax/sip/gateway_mix1
tests/fax/sip/gateway_mix3

Historically, ast_channel_make_compatible() did nothing if the channels
were already "compatible" even if they had a sub-optimal translation path
already setup.  With the changes from ASTERISK-24841 this is no longer
true in order to allow the best translation paths to always be picked.  In
res_fax.c:fax_gateway_framehook() code manually setup the channels to go
through slin and then called ast_channel_make_compatible().  With the
previous version of ast_channel_make_compatible() this was always a
no-operation.

* Remove call to ast_channel_make_compatible() in fax_gateway_framehook()
that now undoes what was just setup when the framehook is attached.

* Fixed locking around saving the channel formats in
fax_gateway_framehook() to ensure that the formats that are saved are
consistent.

* Fix copy pasta errors in fax_gateway_framehook() that confuses read and
write when dealing with saved channel formats.

ASTERISK-24841
Reported by: Matt Jordan

Change-Id: I6fda0877104a370af586a5e8cf9e161a484da78d

A potential problem that can arise is the following:

* Bob's phone is programmed to automatically forward to Carol.
* Carol's phone is programmed to automatically forward to Bob.
* Alice calls Bob.

If left unchecked, this results in an endless loops of call forwards
that would eventually result in some sort of fiery crash.

Asterisk's method of solving this issue was to track which interfaces
had been dialed. If a destination were dialed a second time, then
the attempt to call that destination would fail since a loop was
detected.

The problem with this method is that call forwarding has evolved. Some
SIP phones allow for a user to manually forward an incoming call to an
ad-hoc destination. This can mean that:

* There are legitimate use cases where a device may be dialed multiple
times, or
* There can be human error when forwarding calls.

This change removes the old method of detecting forwarding loops in
favor of keeping a count of the number of destinations a channel has
dialed on a particular branch of a call. If the number exceeds the
set number of max forwards, then the call fails. This approach has
the following advantages over the old:

* It is much simpler.
* It can detect loops involving local channels.
* It is user configurable.

The only disadvantage it has is that in the case where there is a
legitimate forwarding loop present, it takes longer to detect it.
However, the forwarding loop is still properly detected and the
call is cleaned up as it should be.

Address review feedback on gerrit.

* Correct "mfgium" to "Digium"
* Decrement max forwards by one in the case where allocation of the
  max forwards datastore is required.
* Remove irrelevant code change from pjsip_global_headers.c

ASTERISK-24958 #close

Change-Id: Ia7e4b7cd3bccfbd34d9a859838356931bba56c23

Currently when Asterisk starts initial qualifies of contacts are spread out
randomly between 0 and qualify_timeout to prevent network and system overload.
If a contact's qualify_frequency is 5 minutes however, that contact may be
unavailable to accept calls for the entire 5 minutes after startup.  So while
staggering the initial qualifies is a good idea, basing the time on
qualify_timeout could leave contacts unavailable for too long.

This patch adds a new global parameter "max_initial_qualify_time" that sets the
maximum time for the initial qualifies.  This way you could make sure that all
your contacts are initialy, randomly qualified within say 30 seconds but still
have the contact's ongoing qualifies at a 5 minute interval.

If max_initial_qualify_time is > 0, the formula is initial_interval =
min(max_initial_interval, qualify_timeout * random().  If not set,
qualify_timeout is used.

The default is "0" (disabled).

ASTERISK-24863 #close

Change-Id: Ib80498aa1ea9923277bef51d6a9015c9c79740f4
Tested-by: George Joseph <george.joseph@fairview5.com>

This change makes the send_notify of the sub_tree
not happen when the sub_tree has been deleted due
to the notify call failing, which avoids a crash.

ASTERISK-24970 #close

Change-Id: I1f20ffc08b192f59c457293b218025a693992cbf

This is the second follow-on to https://reviewboard.asterisk.org/r/4572/ and the
discussion at
http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html



The basic issues are that changes in contact status don't cause events to be
emitted for the associated endpoint.  Only dynamic contact add/delete actions
update the endpoint.  Also, the qualify timeout is fixed by pjsip at 32 seconds
which is a long time.

This patch makes use of the new transaction timeout feature in r4585 and
provides the following capabilities...

1.  A new aor/contact variable 'qualify_timeout' has been added that allows the
user to specify the maximum time in milliseconds to wait for a response to an
OPTIONS message.  The default is 3000ms.  When the timer expires, the contact is
marked unavailable.

2.  Contact status changes are now propagated up to the endpoint as follows...
When any contact is 'Available', the endpoint is marked as 'Reachable'.  When
all contacts are 'Unavailable', the endpoint is marked as 'Unreachable'.  The
existing endpoint events are generated appropriately.

ASTERISK-24863 #close

Change-Id: Id0ce0528e58014da1324856ea537e7765466044a
Tested-by: Dmitriy Serov
Tested-by: George Joseph <george.joseph@fairview5.com>

This is the first follow-on to https://reviewboard.asterisk.org/r/4572/ and the
discussion at
http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html



Since we currently have no control over pjproject transaction timeout, this
patch pulls the pjsip_endpt_send_request function out of pjproject and into
res_pjsip/endpt_send_transaction in order to implement that capability.

Now when the transaction is initiated, we also schedule our own pj_timer with
our own desired timeout.

If the transaction completes before either timeout, pjproject cancels its timer,
and calls our tsx callback where we cancel our timer and run the app callback.

If the pjproject timer times out first, pjproject calls our tsx callback where
we cancel our timer and run the app callback.

If our timer times out first, we terminate the transaction which causes
pjproject to cancel its timer and call our tsx callback where we run the app
callback.

Regardless of the scenario, pjproject is calling the tsx callback inside the
group_lock and there are checks in the callback to make sure it doesn't run
twice.

As part of this patch ast_sip_send_out_of_dialog_request was created to replace
its similarly named private function.  It takes a new timeout argument in
milliseconds (<= 0 to disable the timeout).

ASTERISK-24863 #close
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>

Change-Id: I0778dc730d9689c5147a444a04aee3c1026bf747

This change adds the following:

1. A query set implementation. This is an API that allows queries to be executed in parallel and once all have completed a callback is invoked.
2. Unit tests for the query set implementation.
3. An external PJSIP resolver which uses the DNS core API to do NAPTR, SRV, AAAA, and A lookups.

For the resolver it will do NAPTR, SRV, and AAAA/A lookups in parallel. If NAPTR or SRV
are available it will then do more queries. And so on. Preference is NAPTR > SRV > AAAA/A,
with IPv6 preferred over IPv4. For transport it will prefer TLS > TCP > UDP if no explicit
transport has been provided. Configured transports on the system are taken into account to
eliminate resolved addresses which have no hope of completing.

ASTERISK-24947 #close
Reported by: Joshua Colp

Change-Id: I56cb03ce4f9d3d600776f36928e0b3e379b5d71e

This new macro allows a single line to add all additional
sources to a module.  This helps prevent modules from
missing steps, and makes future changes easier since
they can be made in a single place.

ASTERISK-24960 #close
Reported by: Corey Farrell

Change-Id: I38f12d8b72c5e7bb37a879b2fb51761a2855eb4b

Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.

Specifically, it does the following:

* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
  remove passing the version in with the macro. Other facilities
  than 'core show file version' make use of the file names, such as
  setting a debug level only on a specific file. As such, the act of
  registering source files with the Asterisk core still has use. The
  macro rename now reflects the new macro purpose.

* main/asterisk:
  - Refactor the file_version structure to reflect that it no longer
    tracks a version field.
  - Remove the "core show file version" CLI command. Without the file
    version, it is no longer useful.
  - Remove the ast_file_version_find function. The file version is no
    longer tracked.
  - Rename ast_register_file_version/ast_unregister_file_version to
    ast_register_file/ast_unregister_file, respectively.

* main/manager: Remove value from the Version key of the ModuleCheck
  Action. The actual key itself has not been removed, as doing so would
  absolutely constitute a backwards incompatible change. However, since
  the file version is no longer tracked, there is no need to attempt to
  include it in the Version key.

* UPGRADE: Add notes for:
  - Modification to the ModuleCheck AMI Action
  - Removal of the "core show file version" CLI command

Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e