For now, the back-end is just able to return two hard-coded podcast
channels when all the channels are requested. Everything else is "TODO".

The view can show the podcast channels and episoded provided by the
back-end but cannot play them yet. The file podcastsviewcontroller.js
still contains a lot of copy-pasted code from the
albumsviewcontroller.js which should be refitted or removed.

The listheading widget was being rendered incorrectly in case the
element had no details button enabled.

The podcast episode, channnel, and image are now properly shown in the
player control bar, in the mediaSession integration, and in the desktop
notification.

All these new classes and definitions are not yet used for anything.

The `occ` command `music:podcast-add` can now be used to add a single podcast
channel from a RSS feed and the command `music:podcast-reset` can be used to
reset all the previously added channels along with their episodes.

Get the data from the database tables instead of fetching it on the fly from
a few hard-coded RSS feed URLs.

…cast-add`

Implemented REST API endpoints to subscribe to a podcast channel, to
unsubscribe it, to get an individual podcast channel and to reset all the
subscribed channels.

It is at least theoretically possible that there would we identical podcast
channels with differing RSS feed URLs. In such case, we should allow
duplicate episode `guid`s to exist.

As part of this change, a new module podcstService was created to host
the new functions. Also the handling of the creating/subscribing a new
podcast channel was moved from navigationController to this new service.

To achieve this, a support had to be added to the listHeading directive
to attach an actions menu. The menu contents are injected when
instantiating the directive.

The new instance used to be always appended to the end of all instances
although often this was not the correct place, according the order of
the elements on the UI. Hence, the lazy loading didn't work correctly
before reinitializing the view by navigating to another view and back.

On some podcast channels, the <lastBuildDate> tag changes very often,
e.g. once every 15 minutes. This caused a lot of unnecessary updates on
the database contents with such channels.

- The command now supports defining multiple RSS feed URLs at once

- When adding a feed for multiple users, the feed is now fetched and
  parsed only once, and not separately for each user

This facilitates code reuse when adding the podcast support for the
Subsonic and Ampache APIs: The class PodcastService contains
API-agnostic logic while PodcastApiController is just a thin wrapper
for it, providing the adaptation to the REST API provided for the web
UI.

The entity classes PodcastChannel and PodcastEpisode now have functions
called toSubsonicApi. These replace the former functions
SubsonicController::podcastChannelToApi and
SubsonicController::podcastChannelToApi. Similar design was previously
applied to the Ampache API conversion of the podcast entity types. The
target of this refactoring is to reduce the size of the monolithic
SubsonicController.

Similar refactoring should be eventually made to the other entity
types, too, but that does not belong under this feature branch.

After setting the position of the <h2> element as 'relative', also the
position of the neighboring .albumart element must be 'relative'.
Otherwise, the padding of the <h2> will shadow the .albumart element,
making it impossible for the element to receive hover and click events.

- The Subsonic API specification doesn't mention anything about
  starring with podcasts, but at least DSub and Ultrasonic allow
  starring podcast episodes and that seems to work with the official
  Subsonic demo server. Our implementation now supports starring also
  podcast channels, although no known client does that.

- The Ampache API specification defines flagging support for both
  podcast channels and episodes, and this is now implemented

- The Ampache API specification does not define support for podcasts on
  the action `stats` which can be used, among other things, to fetch the
  flagged entities. However, we support the types `podcast` and
  `podcast_episode` also here, as an extension to the specified API.

- The property `flag` was added to all Ampache results containing
  flaggable entities. This has probably been added to the spec in some
  4.x version.

Note: This change required incompatible changes on the database table
`oc_music_bookmarks`. Hence, all previous bookmarks need to be dropped
when updating the application.

These pieces of information are not directly available in the RSS feed
but they can usually be evaluated from the available information. The
major motivator for this improvement was that the Jamstash client
depends on the `suffix` field to be able to play the episode at all.
Also, Ultrasonic client showed an ugly looking "-1 kbps" on each
episode while there was no bitRate available.

The command may be used to refresh podcasts of one or several users
from their respective sources.

Giving the option `--older-than=<HOURS>` for `occ music:podcast-update`
has the effect of skipping all channels which have been checked for
updates within the last <HOURS> hours. The <HOURS> may be a floating
point value, allowing sub-hour resolution.

- Null-coalescing operator doesn't work with method calls, we would
  need the null-safe operator ?-> but that comes only with PHP8.0

-  Parameter default value was forgotten from
  PodcastService::updateAllChannels

- Added more type declarations to CoverHelper and removed the
  type-hinting from the method ::getHashKey as that confused
  Scrutinizer (the tool assumed that type-hinting is somehow enforced,
  and the `else` branch on argument type checking would be dead code)

By default, each channel is checked for updates every 24 hours. This
interval may be altered by setting another value in config.php with the
key `music.podcast_auto_update_interval`. The automatic checking may
also be disabled altogether by setting a negative value for the
previously mentioned key.

This same piece of logic, truncating a long HTML description and expanding it
on click, was repeated three times in the various details templates. Now it
is a reusable directive which opens the road to apply it also on the podcast
descriptions (which is not done yet).

The full description may be viewed by clicking the truncated description.

The option may be give to force the updating of the episodes of all the
targeted podcast channels, even when the podcast feed has not changed at all
since the previous update. This may be desirable during the development when
the parsing of the feed is changed by any means. It might be useful for the
end-user, too, in case the database update somehow got unexpectedly aborted
during the previous attempt.

- Extract also the season number from the podcast feed if available

- The episode number is shown in the Podcasts view for each episode where
  available. If there is also a season number, the episode number is prefixed
  with it like "season-episode", e.g. "3-14.".

- Sometimes also the title field in the RSS field contains the episode
  numbers. If the same number is present separately and as part of the title,
  then attempt to strip it off the title.

- The season number was added to the episode details pane, too

- The episode number was added to the Subsonic responses as property `track`.
  According to the Subsonic XML schema, the podcast episodes may contain all
  the same properties as the "normal" audio tracks. However, the tested
  clients (DSub and Ultrasonic) didn't seem to show the `track` property on
  episodes.

When subscribing to a podcast channel, add the available episodes to the DB
in reverse order compared to the order of the RSS feed. Typically, the most
recent episode is the first in the list, so this means adding the episodes
from oldest to newest. Then, when new episodes are published, they will
obviously be added after the first patch of the episodes, maintaining the
same "oldest to newest" logic. Then, when returning the episodes through the
REST API, the list is reversed once more to get the newest episodes first.

The play (or pause) icon was not shown in the episode list on the Podcasts
view in front of the currently playing (or paused) episode.

…null"

Many columns were accidentally marked as "not null" although they may quite
well be missing in the RSS feed. This didn't break the application because
the implementation details in the BusinessLayer were such that empty strings
got stored instead of null values.

The`occ music:podcast-add` was actually totally broken because of a
copy-paste error.

This is probably rarely useful but should be there for consistency of the UX
with all the other views.

…cally

When clicking the title or image of a podcast channel, the contained episodes
are now enqueue to the play queue in chronological order. That is, they are
played from bottom to top.

It's not quite clear if this method should return the episodes according to
their original publish dates or by the order in which they have been added to
the database. Now it's doing the latter which was a bit easier to achieve.

The Subsonic API version has been bumbed to 1.13.0 to advertise the
availability of this method; at least DSub uses only methods belonging to the
claimed API version. The other new methods from v1.12.0 and 1.13.0 are
`getTopSongs`, `getPlayQueue`, and `savePlayQueue`, which have been stubbed
for now.

There's no technical reason, why there couldn't be collisions between
track IDs and podcast episode IDs. This has to be taken into account
when evaluating if a track should be visualized as the "current track"
or not.

NC core provides suitable styling for this but OC core does not. Hence,
we need to define the style on our own. The correct kind of styling
already existed in style-navigation.css but that was applied only
within the actions menu. These style definitions were now moved to
their own file style-actions-menu.css, and they were made to apply both
on the navigation pane and elsewhere within the Music app.

Previously, while there were no podcast channels, the actions menu item
"Reload channels" only appeared disabled but it could actually be
clicked. This triggered a toast with text "All channels were already
up-to-date".

Shown while waiting for the contents for the pane.

When the details pane (for any content type) was closed and then opened
again for any content type requiring closing, there was a flicker when
the previous content was visible on the screen for a fraction of a
second before being replaced by the loading spinner. This was visible
at least when opening details pane for a podcast channel/episode, a
track, or an album.

Also, when creating the first channel, there is now a loading spinner
shown in the view.

To facilitate all this, all methods of PodcastService were modified to
return promises. This replaced signaling via $rootScope.$emit which
was really designed only to be used when triggering operations from the
navigation pane actions menu.

The same format is used also on the response of the Ampache action
`handshake`. The example responses in the Ampache API documentation
actually use the American format like "08/19/21 22:53 PM" but I hope
that this is just an error in the spec and/or in Ampache SW since using
ambiguous format like that in any API makes no sense.

This timestamp is part of the specified Ampache podcast responses so we
need it after all. It is now also included in the channel details shown
on the web UI. This field is still excluded when judging if the RSS
feed has actually changed after the previous podcast update (because on
some channels, the lastBuildDate changes very ofter without any other
changes). This means that if only the lastBuildDate is updated in the
feed, then the user will not see this even with manual update from the
UI.

The `--force` flag now forces an update also on the data stored in the
oc_music_podcast_channels table. Previously, the forcing was applied
only on the episodes table.

Scrutinizer doesn't know that object of type SimpleXMLElement may be
evaluated as false, hence claim that the argument could be actually
null.

The support was almost there, but enabling it for this content type had
been forgotten previously.