the language, which is what you refer to in the first bullet point. A package within a DAR is expressed in the LF language. It is not the same as “DAML” or “the DAML language”; that would be the compiler input, whereas “LF language” is the compiler output.
the value, a way to permanently store contract payloads and choice arguments. These correspond to values you can manipulate in DAML, but only permit a subset known as “serializable”.
the transaction, the result of command processing in the engine, encoded as creates, exercises, fetches, &c. LF transactions incorporate LF values where needed to store contract payloads, choice arguments, and choice return values.
The language is commonly referred to as simply “DAML-LF” or “LF”, whereas the others are referred to as e.g. “LF values”.
The LF value and LF transaction formats are not related in any way to how DAML values and transactions are sent over the gRPC Ledger API or the JSON API. LF formats have numerous wrinkles to satisfy permanent backward compatibility that are not appropriate for designing applications with the API.
The governance document goes into much more detail about the LF formats and their design principles. Following that, there are three specification documents corresponding to the language, value, and transaction LF formats. Please consult these documents for further details.
To add to Stephen’s response: the participant nodes that are not running the classic Sandbox use the Write Service to submit the computed transaction to the underlying ledger. The interface there is Scala rather than gRPC, but the Scala object can be serialized to the protobuf above (a possibility which most ledgers will use in practice).