Merge branch 'amanzano/37-refactor-library-rpc-implementation-of-admire-update_adhoc_storage' into 'main'

Resolve "Refactor library RPC implementation of `admire::update_adhoc_storage`"

This MR moves the implementation of the RPC construction for 
`ADM_update_adhoc_storage` to `admire::detail` in `impl.[ch]pp` 
similarly to other RPCs already refactored. This includes changing 
the C ADM_types to native C++ types.

Closes #37

See merge request !48

Resolve "Make `admire::error_code` a fully fledged class"

This MR redefines the `admire::error_code` typedef transforming it into
a fully-fledged C++ object.

This has the following advantages:

1. The default `error_code` constructor initializes to `ADM_SUCCESS`.
   Thus, we can now do `error_code ec;` instead of `error_code ec = ADM_SUCCESS;`.
2. `error_code`s can be constructed explicitly from `ADM_return_t` values.
3. `error_code`s can be constructed explicitly from `int32_t` (for RPC types).
4. `error_code`s can be converted implicitly to `ADM_return_t`, which makes code
   less verbose when returning from C++ code to the C code.
5. `error_code`s are convertible to `bool`. This means that we can now do

   ```c++
       error_code ec = fun();
       if(ec) { /* there was an error, do something */ }
   ```
   
   whereas previously we were forced to explicitly check against `ADM_SUCCESS`.

   ```c++
       error_code ec = fun();
       if(ec != ADM_SUCCESS) { /* there was an error, do something */ }
   ```

6. `error_code`s provide `value()`, `name()`, and `message()` functions that make
   them much more flexible.
7. Several `error_code` constants are defined to avoid using `ADM_return_t` 
   directly in C++ code, hopefully making the code more readable:
   
   ```c++
      constexpr error_code error_code::success = error_code{ADM_SUCCESS};
      constexpr error_code error_code::snafu = error_code{ADM_ESNAFU};
      constexpr error_code error_code::bad_args = error_code{ADM_EBADARGS};
      constexpr error_code error_code::out_of_memory = error_code{ADM_ENOMEM};
      constexpr error_code error_code::entity_exists = error_code{ADM_EEXISTS};
      constexpr error_code error_code::no_such_entity = error_code{ADM_ENOENT};
      constexpr error_code error_code::adhoc_in_use = error_code{ADM_EADHOC_BUSY};
      constexpr error_code error_code::other = error_code{ADM_EOTHER};
   ```

Also, most of the implementation is `constexpr`, which is always nice.

Closes #81

See merge request !61

Merge branch 'amiranda/90-internal-adhoc_storage_info-should-offer-update-functions-to-simplify-code' into 'main'

Resolve "`internal::adhoc_storage_info` should offer `update` functions to simplify code"

Closes #90

See merge request !60

Resolve "`ADM_update_job()` should only allow changing the job resources"

This MR removes the `ADM_job_requirements` argument from `ADM_update_job`. 
By design, job requirements can only be defined when the job submission 
occurs which means that, as of today, they cannot be changed dynamically.
Thus, it doesn't make sense to be able to change them and removing
the argument simplifies the daemon.

Closes #89

See merge request !59

Resolve "adhoc_storage instances should keep track of jobs using them"

This MR associates registered adhoc storage instances with registered jobs.

To do so, it modifies both the `job_manager` and the `adhoc_storage_manager`
classes to store `shared_ptr`s to `admire::internal::job_info` and 
`admire::internal::adhoc_storage_info` records. This allows returning the 
pointers when checking for information as well as modifying the records in
a synchronized manner.

To keep track of adhoc_storage usage, the new internal `adhoc_storage_info` 
type includes a `std::shared_ptr<job_info> m_client` field that models the 
association. As of today, an adhoc storage instance can only have a single
job client associated. Trying to add more will result in error.

Closes #85 #86 #88

See merge request !58

Print error messages to stderr instead of stdout

Closes #86

Closes #88

* adhoc_storage: Add job client information

* adhoc_storage_manager: Now stores adhoc_storage_info records and
  provides functions to update them.

* adhoc_storage_info: New synchronized type keeping updated information
  about the client job assigned to a adhoc_storage instance

* adhoc_storage: The context can now be updated using a new update()
  function (non-synchronized for now, because it is only ever called
  via the adhoc_storage_manager).

* job_info: Type is now synchronized.

* errors: Add ADM_EADHOC_BUSY. Fix missing error messages for ADM_ENOENT
  and ADM_EEXISTS.

* abt/shared_mutex: Is now movable.

scord::job_info is now admire::internal::job_info

Merge branch 'amiranda/82-improve-adhoc_storage_manager-in-scord-to-keep-information-about-registered-instances' into 'main'

Resolve "Improve `adhoc_storage_manager` in `scord` to keep information about registered instances"

Closes #82

See merge request !55

Merge branch 'amiranda/84-new-job_manager-locks-on-std-shared_mutex-instead-of-abt-shared_mutex' into 'main'

Resolve "New job_manager locks on `std::shared_mutex` instead of `abt::shared_mutex`"

Closes #84

See merge request !57

Resolve "JOB ID needed in register_job / register_adhoc_storage"

This MR adds an extra argument `slurm_id` for `ADM_register_job()` since
it is required by !40 in order to deploy an adhoc storage instance.

Closes #83

See merge request !56

Resolve "Add `job_manager` component to scord daemon"

This MR adds a `job_manager` singleton object to the `scord` daemon so that
there's a centralized way of managing the information about jobs registered
in the service. The `job_manager` stores `job_info` objects that allow 
accessing the `job` itself, its `resources` and its `requirements` were they 
needed.

It also updates the `ADM_register_job()`, `ADM_update_job()`, and 
`ADM_remove_job()` rpc handlers and fixes some minor errors with error handling.

Closes #79

See merge request !54

Merge branch 'amiranda/78-there-s-no-way-to-select-the-adhoc-storage-type-when-calling-register_adhoc_storage' into 'main'

Resolve "There's no way to select the adhoc storage type when calling `register_adhoc_storage`"

This MR adds a `type` argument both to `ADM_register_adhoc_storage()` and 
`admire::register_adhoc_storage()` so that client code can properly select
the type of the instance to be registered.

Closes #78

See merge request !53

Resolve "server_id should not be optional in adhoc_storage"

This MR makes the `server_id` member in adhoc_storage explicit. The rationale
is that constructors (for the C++ API) or `.*_create()` functions (for the C API)
will most of the time be called from internal code, since client code will rely
mostly on `ADM_register_.*()` to obtain handlers.

In this scenario, there's no possibility for the `server_id` "to not having been 
assigned yet", which is why it was `optional` in the first place.

Also, this MR renames the `user_id` to `name`, and the `server_id` to `id`.

Closes #74 #75

See merge request !51

Similarly for ADM_storage_create(), admire::storage, admire::adhoc_storage,
and admire::pfs_storage.
Also, rename any references to `server_id` to just `id`.