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

There are several locations in the code base where this is done:
buf = ast_realloc(buf, new_size);

This is going to leak the original buf contents if the realloc fails.

Review: https://reviewboard.asterisk.org/r/2832/
........

Merged revisions 398757 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 398758 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 398759 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@398760 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........
  r369001 | kpfleming | 2012-06-15 10:56:08 -0500 (Fri, 15 Jun 2012) | 11 lines
  
  Add support-level indications to many more source files.
  
  Since we now have tools that scan through the source tree looking for files
  with specific support levels, we need to ensure that every file that is
  a component of a 'core' or 'extended' module (or the main Asterisk binary)
  is explicitly marked with its support level. This patch adds support-level
  indications to many more source files in tree, but avoids adding them to
  third-party libraries that are included in the tree and to source files
  that don't end up involved in Asterisk itself.
........
  r369002 | kpfleming | 2012-06-15 10:57:14 -0500 (Fri, 15 Jun 2012) | 3 lines
  
  Add a script to enable finding source files without support-levels defined.
........

Merged revisions 369001-369002 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 369005 from http://svn.asterisk.org/svn/asterisk/branches/10


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369013 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r304950 | tilghman | 2011-01-31 00:41:36 -0600 (Mon, 31 Jan 2011) | 18 lines
  
  Change mutex tracking so that it only consumes memory in the core mutex object when it's actually being used.
  
  This reduces the overall size of a mutex which was 3016 bytes before this back
  down to 216 bytes (this is on 64-bit Linux with a glibc-implemented mutex).
  The exactness of the numbers here may vary slightly based upon how mutexes are
  implemented on a platform, but the long and short of it is that prior to this
  commit, chan_iax2 held down 98MB of memory on a 64-bit system for nothing more
  than a table of 32767 locks.  After this commit, the same table occupies a mere
  7MB of memory.
  
  (closes issue #18194)
   Reported by: job
   Patches: 
         20110124__issue18194.diff.txt uploaded by tilghman (license 14)
   Tested by: tilghman
   
  Review: https://reviewboard.asterisk.org/r/1066
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@304951 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This bug surfaced in 1.6.2 and does not affect code in any other released
version of Asterisk.  It manifested itself as SIP qualify not happening when
it should, causing peers to go unreachable.  This was debugged down to scheduler
entries sometimes not getting executed when they were supposed to, which was in
turn caused by an error in the heap code.

The problem only sometimes occurs, and it is due to the logic for removing an entry
in the heap from an arbitrary location (not just popping off the top).  The scheduler
performs this operation frequently when entries are removed before they run (when
ast_sched_del() is used).

In a normal pop off of the top of the heap, a node is taken off the bottom,
placed at the top, and then bubbled down until the max heap property is restored
(see max_heapify()).  This same logic was used for removing an arbitrary node
from the middle of the heap.  Unfortunately, that logic is full of fail.  This
patch fixes that by fully restoring the max heap property when a node is thrown
into the middle of the heap.  Instead of just pushing it down as appropriate, it
first pushes it up as high as it will go, and _then_ pushes it down.

Lastly, fix a minor problem in ast_heap_verify(), which is only used for
debugging.  If a parent and child node have the same value, that is not an
error.  The only error is if a parent's value is less than its children.

A huge thanks goes out to cappucinoking for debugging this down to the scheduler,
and then producing an ast_heap test case that demonstrated the breakage.  That
made it very easy for me to focus on the heap logic and produce a fix.  Open source
projects are awesome.

(closes issue #16936)
Reported by: ib2
Tested by: cappucinoking, crjw

(closes issue #17277)
Reported by: cappucinoking
Patches:
      heap-fix.rev2.diff uploaded by russell (license 2)
Tested by: cappucinoking, russell


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@261496 65c4cc65-6c06-0410-ace0-fbb531ad65f3

"Bad Things" would happen if Asterisk was compiled with DEBUG_THREADS, but a
loaded module was not (or vice versa).  This also immensely simplifies the
lock code, since there are no longer 2 separate versions of them.

Review: https://reviewboard.asterisk.org/r/508/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258557 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@184512 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(related to issue #14636)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181028 65c4cc65-6c06-0410-ace0-fbb531ad65f3

A heap is a convenient data structure for implementing a priority queue.

Code from svn/asterisk/team/russell/heap/.

Review: http://reviewboard.digium.com/r/160/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176632 65c4cc65-6c06-0410-ace0-fbb531ad65f3