Const-correct object pointers

[jphickey]

For bplib API calls that accept a pointer to an object but do not modify that object, the pointer should be qualified as const. This is important as it allows this API call to be made from application code where the data object is already const. Otherwise, the application developer must "cast-away" the const-ness, which can be risky/dangerous.

Specifically affected BPLIB APIs:

• bplib_store()
• bplib_process() (should be at least)
• bplib_ackbundle()
• bplib_ackpayload()
• bplib_routeinfo()
• bplib_display()

Potentially affected dependent/internal APIs:

• bib_read(), bib_update(), bib_verify()
• enqueue method within bp_store_t (and hence bplib_store_{file,ram,flash}_enqueue() implementations too)
• bp_create_func_t function pointer type (payload parameter)
• cteb_read()
• dacs_read()
• pay_read() and associated payptr member within bp_blk_pay_t
• pri_read()
• sdnv_read()
• v6_send_bundle(), v6_receive_bundle(), v6_receive_acknowledgement(), v6_route_info(), v6_display()
• BP_IOWriteBundle()

Background/Rationale: In general, C/C++ APIs that accept pointers should always be clear as to whether that pointer is used only for input (const, read-only) or may do output as well (non-const).

Note that for use within CFE/CFS, the messages received from Software Bus (SB) are now (or will be) qualified as "const" - because this is a publish/subscribe design with 1:N distribution, the same buffer might be received by many applications. If an application wants to modify the payload in some way, it must always make a copy of the buffer before making the modification, to avoid potential race conditions with other applications that may have received the same buffer.

[jphickey]

Note with respect to bplib_process(): This function mostly does not modify its input bundle, except in one circumstance - The internal implementation v6_receive_bundle() may determine that the block needs to be forwarded without processing, in which case the block flags are actually updated within the buffer (i.e. sdnv_write is invoked). See here:

https://github.com/nasa/bplib/blob/e6e43b3cf644aabc43feaa72aea9c5e2fd99a47f/v6/v6.c#L620-L626

The whole premise of this is a little strange/suspect, somewhat of an oxymoron - in order to indicate the block was forwarded "without processing", it must modify the very block it just said it didn't touch...?