Fix the package recipe for consumers

[thejohnfreeman]

This branch is named clio because this work was driven to support its dependence on libxrpl, but Clio is just an example consumer. These changes should benefit all current and future consumers.

• "Rename" the type LedgerInfo to LedgerHeader (but leave an alias for LedgerInfo to not yet disturb existing uses). Put it in its own public header, named after itself, so that it is more easily found.
• Move the type Fees and NFT serialization functions into public (read: installed) headers.
• Compile the XRPL and gRPC protocol buffers directly into libxrpl and install their headers. Fix the Conan recipe to correctly export these types.

Addresses change (2) in XRPLF/XRPL-Standards#121.

[godexsoft]

I may not know much about the inner workings of rippled but the changes look fine to me.
I'd like to see the one TODO comment getting resolved or maybe an issue number added to it if it is planned as a separate pr.
It would also be great to eventually rename most/all things 'ripple' to something more xrpl-y but i can see how that may be a huge effort and probably is out of scope of this pr.

Thanks for helping Clio out @thejohnfreeman 👍💪

[intelliot]

note: @thejohnfreeman will be making more changes per requests from @godexsoft

[godexsoft]

This PR enables Clio to build successfully on Mac and Linux (tested with AppleClang and gcc11/gcc12) 👍🚀

[thejohnfreeman]

I forgot: one reason I wanted @ximinez's review while we have Windows CI disabled is to verify that the common filename is not an issue in the MSVC build. I know that MSVC, while it is building, reports translation units by filename instead of the full path. I don't know if it's dumping all the object files into one directory, like the way Windows handles shared libraries, but if it is, then I might expect to see a link error.

[ximinez]

I forgot: one reason I wanted @ximinez's review while we have Windows CI disabled is to verify that the common filename is not an issue in the MSVC build. I know that MSVC, while it is building, reports translation units by filename instead of the full path. I don't know if it's dumping all the object files into one directory, like the way Windows handles shared libraries, but if it is, then I might expect to see a link error.

I don't remember exactly when or how, but the CMake config was updated a while back to do the right thing when multiple files have the same name. On top of that, in the linked example (LedgerHeader.cpp), the two files are in different projects (xrpl_core and rippled).

Amusingly, the unity build outputs a warning about potential conflicts for some existing files, but that warning amounts to nothing:

$ cmake --build build/cmake/msvc19.ON --config Debug -- -m
[...]
  Building Custom Rule C:/Dev/rippled/review1/CMakeLists.txt
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(1091,5): warning MSB8027: Two or more files with the name of Manifest.cpp will produce outputs to the same location. This can lead to an incorrect build result.  The files involved are C:\Dev\rippled\review1\src\ripple\app\misc\impl\Manifest.cpp, C:\Dev\rippled\review1\src\ripple\rpc\handlers\Manifest.cpp. [C:\Dev\rippled\review1\build\cmake\msvc19.ON\rippled.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(1091,5): warning MSB8027: Two or more files with the name of Shard.cpp will produce outputs to the same location. This can lead to an incorrect build result.  The files involved are C:\Dev\rippled\review1\src\ripple\app\rdb\backend\detail\impl\Shard.cpp, C:\Dev\rippled\review1\src\ripple\nodestore\impl\Shard.cpp. [C:\Dev\rippled\review1\build\cmake\msvc19.ON\rippled.vcxproj]
  unity_35_cxx.cxx
  unity_34_cxx.cxx
  unity_33_cxx.cxx
[...]

All of which is to say that this branch builds fine in MSVC.

[ximinez]

Very nice restructuring

[intelliot]

Suggested commit message for when this PR is squashed and merged:

Fix the package recipe for consumers of libxrpl (#4631)

- "Rename" the type `LedgerInfo` to `LedgerHeader` (but leave an alias
  for `LedgerInfo` to not yet disturb existing uses). Put it in its own
  public header, named after itself, so that it is more easily found.
- Move the type `Fees` and NFT serialization functions into public
  (installed) headers.
- Compile the XRPL and gRPC protocol buffers directly into `libxrpl` and
  install their headers. Fix the Conan recipe to correctly export these
  types.

Addresses change (2) in
https:/XRPLF/XRPL-Standards/discussions/121.

For context: This work supports Clio's dependence on libxrpl. Clio is
just an example consumer. These changes should benefit all current and
future consumers.

---------

Co-authored-by: cyan317 <[email protected]>

(Feel free to propose an alternative)